Ask HN: What should an ideal developer interview process look like?

A process that I've seen have some success (years ago):

Start with a very, very simple initial phone screen or take-home test, intended to basically verify whether the candidate can write any code, at all. Max 1 hour, weeds out more people than you'd think.

For the first in-house interview, ask the candidate to code up a problem that is representative of your company's work and requires coding a significant amount, ideally 100+ LOC. The problem should not require any major leaps of intuition, dynamic programming, or recursion – all of these are areas where people do way worse when they're nervous, and this is an engineering interview not special forces training. Let them bring their own laptop, give them the prompt, and have them code, although they can ask the interviewer questions at any time. When they're done, go over the question in detail with the expectation that their code compiles and runs, discuss extensions, etc. Max 1 hour. This interview should answer the binary question "can this person promptly produce meaningful working code and discuss it intelligently?"

For the next in-house interview, do a deep dive into a technical project that the candidate worked on that they're proud of. They describe it and you ask questions. Keep asking questions, especially getting at the "why" behind different decisions, for as long as you can – you're trying to get to the borders of their knowledge and intelligence. Look for mastery of the area, thoughtful decisions, and communication skills. Max 1 hour. This interview should answer the question "is this person a thoughtful, effective, smart contributor on a project?" A good answer should make you think "damn, that's really smart, I wonder if I would have thought of that?" at least once.

End with a final behavioral interview, intended to sell the candidate. This is also a last gut check on whether they're insane, dangerous to themselves or others, extremely arrogant, etc. Also use this time to ask the candidate questions about what really matters to them to improve your closing rate. 30 minutes, and can be combined with the step above.

I've liked this system, YMMV. It's a relatively efficient process, doesn't have weird tricks, and based upon a longterm analysis of candidate outcomes was quite effective (this included an analysis of candidates whom we rejected and who rejected us).

Ideal process for me is being placed in front of other engineers and discussing what I did in the past and how I understand their challenges. Meeting the team I’m working with is a plus to see if we are a match. I don’t do tests and stop the process before it gets to that. I also consider talking to HR a waste of time. The company should sell itself to me.

Well said.

For reference, this only works in places where the minimum wage is also a reasonable amount.

In the UK, the minimum wage is laughably poor and in Switzerland it's significantly below the amount needed to live.

A better threshold would be to look at the cost of living _in the area_ and pay a reasonable starting wage that actually lets people live there comfortably.

In US perhaps, elsewhere a job signifies significantly greater income stability.