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

>Talking through a few whiteboard problems and talking about tools they have used (why and how) are sufficient.

I've done interviews with a whiteboarding "tell me about stuff you've worked on" component followed by a test.

It thought it gave a weak signal about the skills of the candidate. I canned it eventually because the test gave a very strong signal and it wasn't telling me anything the test didn't.

>Interviews with higher management is just a redundant filter and another reason for the management to justify their existence.

I agree. I had suspicions in a previous company that this upper management "team fit" interview was adding a race/nationality filter that ended up with good candidates getting dropped.

I’m fully convinced that 70-80% of my energy and brain function during an interview is spent on listening, formulating responses, breathing and in general trying to interact in a social situation with people I don’t know. That leaves very little to solve problems that I’m not prepared to speak about, usually a riddle or coding puzzle that has no bearing on my day to day.

As developers we are a bit introverted so being in a room with 2-3 people knowing that after this there will be another 2-3 people for round 2, is very difficult. As an interviewer I’ve watched candidates open up talking about what they know and why they enjoy being a developer and completely fall apart (sweat, shake, refuse to get out of their chair) when you hand them a dry erase marker and show them the white board.

In the end, I'm always trying to have a "discussion about code" with the candidate. I ask questions that really are easy, but require a certain amount of listening. This way I understand how the candidate behaves in more abstract discussions.

Some examples are things like:

- Walking the candidate through an outdated API (that the candidate isn't familiar with, but should be able to understand given the nature of the job)

- Walk the candidate through code that converts a database query into objects without an ORM. (Candidates who can't do this are incompetent. Really.)

- Discuss commonly-known details of exceptions / error handling in the language that the job is for

- Discuss commonly-known details of memory management in the language that the job is for

- Discuss API choice tradeoffs in an API that the candidate should be familiar with. (I like to pick serialization APIs built into the library in the language we will use.)

Also:

- I try to emphasize how I would do with my interview at the candidate's level of experience

- I have 2nd chances, and will usually stay on the phone for the scheduled interview out of respect. (There are still certain points where I will cut an interview short.)

- Make a decision to hire quickly.

Usually works well.

Signs to reject someone:

Figuring out how to use the teleconference software is an unofficial part of my interview. (Most of my interviews are conducted via teleconference because I'm on a global team.) There are candidates who take 15 minutes to figure out that they can type their phone number into the teleconference web site and it will call them back.

Candidates who want to answer a different question, or keep asking, "why can't I use XYZ" technique usually aren't hired. Again, the purpose is to have a discussion about code and demonstrate understanding of the discussion. I don't want to hire someone who can't adapt when the correct solution to the problem is some tool / design pattern / API / ect that isn't the candidates first choice.

I was, of course, using the story to illustrate the absurdity of the overall situation.

I don't want to leave a secure job for an insecure situation because they're difficult to find. They won't consider a direct hire for a "perfect candidate" -- proving my fears.

My point which perhaps I should have been made more clearly is that they're asking me to leave a direct hire situation for a temp job. They're asking me for a commitment they're unwilling to make themselves.

Power asymmetries suck.

  > It's way too easy to set a project that takes too long. 

They do often take longer than they claim. That's true.

  > Take home projects inevitably have issues ("bugs", if you will). You can't just "resolve" those problems if the person who set it isn't sitting in front of you.

In my experience, you're usually assigned someone you can call or mail with questions. Asking questions is good. Though I usually figure it out on my own.

  > Take home projects take employer skin out of the game. It's way too easy to give out twenty tests and ignore ten of them

Only if they do it wrong. The right way is to give this assignment only to candidates you will definitely want to hire, unless they produce terrible code. The candidate doesn't mail in their code, but presents it to a group of developers who ask questions about it.

This gives the employer skin in the game: they're not going to keep their developers off their work for dozens of candidates who are probably not going to make it; they only bring them out to assess a very likely hire.

I guess some employers use these coding assignments badly. You're totally right to avoid those.

  > I could just have copied someone else's.

But could you have been able to explain the choices of that someone else?

  > You lose a valuable source of feedback which allows you to iteratively improve the test if you're not watching the candidate while they do the test.

Maybe, but to many people, coding on the spot is more stressful than it is at home. Although I've also done some really enjoyable pair programming on what was probably my only long interview day (which had an interview, pair programming, and a game to get to know each other).

  > It's valuable to talk through the solution with the candidate while they do it

But it's also valuable to talk through the solution after they've done it. That's when they have made those trade-offs.