Phone Screen Questions

Steve Yegge from Amazon offers his Five Essential Phone Screen Questions.  It's an old post, but a good one.  His advice is solid.  It's always disappointing to bring in a promising candidate for an interview only to have them bomb.  It would be much better to screen them out early.  Steve give suggestions for what to ask (and not ask) to make a better determination up front.  Most of the advice is universal.  Some is specific to the type of work Steve is hiring for.  For example, he suggests that one of the five areas to probe is scripting and regex.  There are a lot of jobs out there that need this, but not all.  On my team (Audio Test Development in Windows), scripting and regex don't get a lot of use.  Instead, I would tend to ask about OS concepts and debugging.

Steve gives some other good advice.  First, he says that the interviewer needs to direct the interview.  That seems obvious but it is easy to focus on the areas the candidate wants to cover (the things on his/her resume) and forget the things that are missing.  Second, he gives a bar for the answers.  He says that you are looking for a well-rounded individual.  The acceptable candidate does not have to excel at all five points.  Rather, they cannot fall flat in any area.

I concur with most of Steve's advice.  My addition to his is to probe beyond the first-level answer.  I like to ask questions that go deeper until I find the point at which the candidate no longer knows the next level of answer.  It's easy to cram some high-level ideas.  Everyone can say that threads are more "lightweight" than processes, but what does this really mean?  Either the candidate really understands and has some solid second- (or third-) level answers or they don't really know the subject area.  Don't be afraid to ask follow-up questions until the candidate runs out of answers.  You'll get a much better sense for the candidates' strengths and weaknesses.  Of course, if you are going to do this, tell the candidate up front.  It's not fatal to not be able to explain how page tables can be used to map memory across processes.  You don't want them flustered when they mess up.