Difference between revisions of "Interviewing a Technical Candidate"

Revision as of 14:27, 26 August 2014

I've become involved in the interview process at my company. It's been fun to learn the general guidelines we've setup for each other, but on thing I've learned is that interviewing is hard. It frustrates me how little I seem to know about a candidate after an entire hour of time with him and although we have four employees interview each candidate, I'm not confident the sum of parts is a complete picture.

I've tried to be proactive learning more about technical interviews. Time management is especially important. Having only an hour with the candidate I've found some questions can eat up a lot of time without telling me much about the programmer's coding ability or their fit on the team.

Anatomy of a Perfect Technical Hire

Neil Roseman, previously a VP at Amazon, wrote The Anatomy of a Perfect Technical Hire, what he believes to be some good rules. While I don't agree with everything the article as a whole provides some great pointers.

• Don’t forget to introduce yourself to help work out everyone’s nerves.
• “Tell me about your background” is not a useful question for a tech interview.
• Pick specifics out of a resume to determine what the candidate actually did. Remember, you want people who get stuff done. Period.
• Probe when you see a resume with a long list of skills. Separate the truth from filler.
• Don’t “try out” new questions on candidates. Know what a good answer sounds like.
• Make sure you have them write code! This is too often skipped.
• Dig into algorithms, data structures, code organization, simplicity.
• Use some questions that are vague and open-ended. See if they ask you questions to find out more.
• Ask a design question. See how people think about a bigger picture problem.
• Create core competences for your company. Make sure candidates measure up well.
• Make it tough but fun. Good developers want to know they’re talking to smart folks.

Time Management

As I said, I feel like time goes by so fast in an interview. It's important to keep a good schedule so you get what you want out of the candidate and also the candidate gets what he needs out of the interview (they need to get sold on your company during the interview). For an hour long meeting I like to use the first ten minutes introducing myself and going over their resume. This is followed by about forty minutes of coding starting with an easy problem and getting harder and deeper as they progress. The last ten minutes of the interview is strictly for the candidate to ask me questions.

The First Ten

After a quick introduction I start going over parts of the candidate's resume with them. I've already gone over the resume beforehand and highlighted specific sections I want to talk about. Roseman suggests focusing on percentages in particular.

They might think it sounds good to say 'I improved system availability by 50%', but if we’re hiring someone for a system engineering role, I need to know they actually did that. -Roseman

If they say they've designed an architecture, have them diagram it on the board. Ask them what part of the design they did and dig deep to determine whether they were actively shaping in the process or just a participant.