Here are some highlights from The Guerrilla Guide to Interviewing (version 3.0) - Joel on Software:
"In principle, it’s simple. You’re looking for people who are
- Smart, and
- Get things done.
Here’s a typical plan for interviewing a programmer:
- Introduction
- Question about recent project candidate worked on
- Easy Programming Question
- Pointer/Recursion Question
- Are you satisfied?
- Do you have any questions?
The introduction phase of the interview is intended to put the candidate at ease. I ask them if they had a nice flight. I spend about 30 seconds telling the person who I am and how the interview will work. I always reassure candidates that we are interested in how they go about solving problems, not the actual answer.
Recent Project
Part two is a question about some recent project that the candidate worked on.... Again, ask open-ended questions and sit back and listen, with only the occasional “tell me more about that” if they seem to stall....
What should you look for during the open ended questions?
One:Look for passion. Smart people are passionate about the projects they work on.Two: Good candidates are careful to explain things well, at whatever level. I have rejected candidates because when they talked about their previous project, they couldn’t explain it in terms that a normal person could understand.
Three: If the project was a team project, look for signs that they took a leadership role.
Most of the time in the interview, though, should be spent letting the candidate prove that they can write code.
Easy Programming Question
If the basic concepts aren’t so easy that you don’t even have to think about them, you’re not going to get the big concepts.
Pointer/Recursion Question
the best programmers all have an easy aptitude for dealing with multiple levels of abstraction simultaneously. In programming, that means specifically that they have no problem with recursion (which involves holding in your head multiple levels of the call stack at the same time) or complex pointer-based algorithms
Are you satisfied?
Even though the format of the interview is, superficially, just a candidate writing some code on the whiteboard, my real goal here is to have a conversation about it. “Why did you do it that way?” “What are the performance characteristics of your algorithm?” “What did you forget?” “Where’s your bug?”
Do you have any questions?
As the last step in an interview, ask the candidate if they have any questions. Remember, even though you’re interviewing them, the good candidates have lots of choices about where to work and they’re using this day to figure out if they want to work for you.
In the past, I’ve used “impossible questions,” also known as “back of the envelope questions.” Classic examples of this are “How many piano tuners are there in Seattle?” The candidate won’t know the answer, but smart candidates won’t give up and they’ll be happy to try and estimate a reasonable number for you.
