For the last few years I have been one of the primary people to interview potential new hires. Interviewing programmers is very difficult because what we do is so vast that knowing it all is impossible. Over time I learned from the interviews and came down to answering one question. I will even say that me and a couple co-workers at a previous job got really good at this process. When we hired a person we knew exactly what we were getting. If the person was senior, we knew it. If the person was a mid-level developer that wouldn’t really get much better… we knew it. If the person wasn’t worth hiring we knew it*. The results of hiring each has proven our process.
What do you want to figure out about the person sitting next to you?
This can really vary from place to place, but ultimately I have two things I’d like to have answered.
How wide and deep is their knowledge?
How wide and deep is their experience?
What I’ve found is that it is easy for some people to memorize the text book answers. However figuring this out is very easy, and ultimately answers the second question. You ask a question and you let them give you the right answer, but then ask them a follow up or two about the same topic. Generally in relation to how they have used or experienced it on the job.
Ultimately I’ve found the following process to be very beneficial:
1. 15 minute phone screen. Is this person worth bringing in for a longer period of time?
2. One hour technical interview that includes a technical code problem.
I’ve also heard of companies, and I’ve yet to work for one that would allow this, that will give a programmer a simple project to do at home before the face to face interview.
I’ll cover a few things over the next few blog post. I’ll give a list of programming problems that I’ve seen used and a list of questions that I’ve used.
* Yes, in spite of an entire team of programmers recommending a person not get hired our managers hired them. Our reservations were soon proven to be accurate.