[smallerfish]

No, I'm not doing leetcode or algorithm questions - it's basically "build a [tiny] product to specs", in a series of steps. I'm evaluating candidates on their process, their effectiveness, their communication (I ask for narration), and their attention to detail. I do review code afterwards. And, bear in mind that this is only round 1 - once I talk with the ones who do well, I'll go deep on a number of topics to understand how well rounded they are.

I think it's a reasonably balanced interview process. Take home tests are useless now that LLMs exist. Code interviews are very time consuming on the hiring side. I'm a firm believer that hiring without some sort of evaluation of practical competence is a very bad idea - as is often discussed on here, the fizzbuzz problem is real.

[majormajor]

> it's basically "build a [tiny] product to specs", in a series of steps

That seems like exactly what the person you're replying to is saying - that sounds like basic standard product-engineering stuff, but simpler, like any of a million examples out there that an LLM has seen a million times. "Here's a problem LLMs are good at, wow, the people using the LLMs do best at it." Tautolgy.

So it's great for finding people who can use an LLM to do tiny product things.

In the same way takehomes had all the same limitations. More power to you if those are the people you are looking for, though.

But it also sounds like a process that most people with better options are gonna pass on most of the time. (Also like with takehomes.)

[smallerfish]

> "Here's a problem LLMs are good at, wow, the people using the LLMs do best at it."

Yes, product engineering, the thing that 90% of developers do most of their time.

[mrheosuper]

But what LLM haven't look at ?

[kuschku]

LLMs have looked at everything that exists so far. If all you're creating is yet another "Uber for Dogs", LLMs will do fine.

But if you want to create a paradigm shift, you need to do something new. Something LLMs don't yet know about.

[branko_d]

> I ask for narration

That's a mistake. There are plenty of people who are not good multitaskers and cannot effectively think AND talk at the same time, myself included.

IMHO, for programming, monotaskers tend to do better than multitaskers.

[computerdork]

Haven't coded for a couple years (but have been a dev for two decades) and haven't used LLM's myself for coding (not against this), so am really just curious, wouldn't you want to know if a dev can solve and understand problems themselves?

Because it seems like tougher real-world technical problems (where there are tons of dependencies with other systems in addition to technical and business requirements) needs for the dev to have an understanding of how things work, and if you rely on an LLM, you may not gain enough of an understanding of what's going on to solve problems like this...

... Although, I could see how devs that are more focused on application development and knowing the business domain is their key skill, wouldn't need to have as strong an understanding of the technical (no judgement here, have been in this role myself at times).

[smallerfish]

> Haven't coded for a couple years (but have been a dev for two decades) and haven't used LLM's myself for coding (not against this), so am really just curious, wouldn't you want to know if a dev can solve and understand problems themselves?

Yes, definitely, though I lean more on the 1:1 interviews for that. I understand the resistance to this from developers, but there's a lot of repetition across the industry in product engineering, and so of course it can be significantly optimized with automation. But, you still need good human brains to make most architectural decisions, and to develop IP.

[computerdork]

Ah, I see, round 1 is just the initial weeder, while on top of this, you'd like devs that are using LLM's for automation. Sounds like a good balance:)