You’re right, it can be hard to find signal to noise; however, there are ways to reduce noise.

You’re right, it can be hard to find signal to noise; however, there are ways to reduce noise. For example, you could have some screening questions that look for knowledge of language, framework, or domain; you can combine these with questions about learning:

You don’t want to hire people that will only do what they currently know and nothing else, otherwise you’re stunning their growth & the potential for innovation.

So, instead, if at any time a candidate says “I don’t know”, ask them how they’d learn or find out, ask them if there’s patterns that they can potentially apply to a problem that they’ve not seen before.

Hiring great people does take time, however, all the work shouldn’t be on the candidates. Perhaps ask candidates to conduct a code review on an existing piece of code (in their own time, arbitrary low time limits increase stress).

Also, just because you’ve scheduled an hour interview, don’t be afraid to say “you’re not the right fit” after 15 minutes, both as the hiring person and as the candidate.

If you really insist on using a coding challenge then it should be graded based on a clear and published checklist (but then, I’m pretty sure it won’t actually tell you anything about the candidate, anyone can tick boxes)

You really want to know a few things: can the candidate do the job? If not, how quickly can they learn? How do they communicate? How do they receive communications? How do the reason about a concrete problem?

Code is but a small part of our jobs as software engineers, why are we making it the largest part of our job interviews?