Technical Interviews

May 02, 2011 - hiring interview

I’ve recently been doing a few technical interviews with candidates for software developer positions. I haven't done any in a long time and I'd assumed I'd go back and trot out some of the old technical ‘trivia’ questions (“In .NET, is a string a value type or a reference type?” etc). Alternatively, perhaps I’d get organised and do some whiteboard code problems like Joel suggests — however, I came across a rebuttal from John DeRosa that convinced me this approach isn't all it's cracked up to be.

Aaron Swartz suggests you’re only trying to answer three questions in a job interview:

  1. Have they done this job in the past?
  2. Are they smart?
  3. Could I work with them?

I would opine those are in increasing order of importance: experience is easy to gain, skills can be improved up to a limit, but if someone’s a tosser they’re probably always going to be a tosser.

The questions I found I ended up being more useful were the ones along the lines of:

The goal is to get the candidate talking about him/herself and have more of a conversational interaction with them. It’s easy to embellish a job history, but much more difficult to give a plausible retrospective analysis of your role on a fictitious project, so question 1 is covered by going over recent work the candidate has done. Question 2 is fairly easy to pick up on during a bit of to & fro — challenging one or two statements they make gives you a good feel for whether they’re parroting conventional wisdom or they’ve acquired a good understanding of the subject. It’s also always a good idea to teach them something and see whether they internalise or dismiss it, as per one of Aaron’s suggestions.

Lastly, a conversation is the only way you're going to be able to assess the answer to question 3. This is obviously a subjective call, but you know yourself & your team and you should get a good feel over 60-90 minutes as to whether they'll fit into the team. I can’t stress enough how much more important cultural fit is than any other consideration. Software development is a team sport.