Tips on passing the phone screen

And these are two of the most well known. I would say that these two phone screens will cover a good bit of ground. You can’t go wrong by being prepared for these questions.

The phone screen is your time to pitch me on the idea of you.  You’ve got to control your speaking.  You’re nervous and your brain is in fight or flight mode, but in order to succeed, you have to control that.

• Smile when you answer the phone. A genuine smile makes you sound much more approachable.  You should act as if this person is the person you’ve been looking forward to speaking to the entire week. They probably are. Act that way.

• Don’t take too long to answer the question: If I ask you about your job history, the answer should take less than a minute. Go ahead, time yourself talking about your job history.  Can you do it in less than a minute and still say everything you want to say?

Here’s my one minute job history:

I started programming when I was just old enough to touch a PC, have been around PCs ever since. In college I wrote a Winforms client tracking application for a non-profit, and while in the Army I wrote an application that assisted with the daily strength of the unit and sent that report to various agencies, reducing reporting time by a factor of 8. After the Army I took a web programming contract in Perl writing software that allowed companies to test their employees on Compliance (like Sarbanes Oxley training), and after that took a dual sysadmin/programmer role at an Auto Auction. In that time I wrote an application that automated point of sale setup by 67% for the 20 aucion lanes; after that I spent a year writing features that improved sales for a Human Resources Performance Evaluation product. Most recently I’ve been leading a team that writes code for the Army that allows them to document the breakdown of their units.

Notice the highlights. I don’t tell the interviewer just what I did, I tell him things that improved performance or improved reporting time (and ultimately saved companies money).  This is my first impression. This is what they learn about me: Whatever I do, I make sure it has a solid impact on the company I work for.  If they ask about these things, they find out that that in at least half the situations I was in, I came up with solutions that no one else thought about. No fluff, just the facts.

• Not being specific enough. If I ask you a question about how to create a memory leak in a .NET Winforms application, that’s a specific question with specific answers (register an event handler to code that has a different lifespan than the code registering, and don’t dereference the event handler when you’re done in the code with the shorter lifespan (through its Dispose(), or Close() method). You can also create a memory leak by creating static collections and never cleaning up the collection when you’re finished with it (I’m thinking about those ugly global collections that people insist on creating for ‘performance’).  But notice the answer, I used specific .NET terms (Close(), Dispose(), Event Handlers, and static collections). I didn’t say, “By creating a list and never cleaning it up”.
• Bullshitting the interviewer.  If a candidate puts ‘expert’ on their résumé, I’m going to take that ‘expert’ tag for a spin.  I’ll ask them them to describe garbage collection in .NET. I’m not looking for an ‘expert’ answer, I’m looking for the Reader’s digest answer.  Invariably the experience of the candidate inversely correlates to the adjective they put on their résumé. It has a little brother:
• Don’t fudge your involvement in a project. If your résumé says that you implemented a solution, then you should be prepared to tell me top to bottom about that solution. You implemented it, remember? If you can’t, then you should rethink it’s position in your résumé.
• No practical experience. I like to ask a lot of questions that reflect problems I’ve had to solve while working with C# and .NET. In ASP.NET, memory issues come up because most programmers don’t realize you need to unsubscribe from event handlers when you dispose of the form.  It happens in Winforms as well; and it’s something that anyone who has spent any time with a production application has run into.  In other cases, candidates will put object-oriented design as a skill on their résumé and not be able to tell me about how virtual and ‘new’ work in class methods. Knowing C# *does not mean* that the person knows what object oriented programming is.  The number of terrible C# applications out there attests to that.
• Missing the trick question. I like to ask candidates how they rate in their favorite language (usually C#) on a scale from 1-10. Invariably, *everyone* says ‘8’. Taking a page from Eric Lippert’s play book, I ask this question to see how they’ll respond.  The best candidates will ask questions about this question, they know it’s never as simple as 1-10. Or, I’ll directly contradict something that .NET says about a class. For instance, since Generics are all about type-safety, I’ll saying something like, “I don’t like to use Generics because I have to constantly box and unbox items that I view in a generic collection.”  Good candidates will find a way to tell me that I’m an idiot, and bad candidates will agree.
• Not asking questions about the company or team.  Every software team is different. There are different personalities, different management styles, and different goals.  You will never find two teams that work exactly the same, so why wouldn’t you ask the interviewer how his team works? Good candidates will ask questions like: What development methodology does your team use and why? Do you have Unit tests? They may even pull out questions from the Joel Test. Especially confident candidates will ask more probing questions. The fewer questions a candidate asks, the more it shows they don’t care about where they work, and that’s a red flag.
• Practice, practice, practice. By the time the phone screen comes around, if you don’t know the subject matter, you’re probably not going to make it.  Even if you do know the subject matter but can’t explain that to the interviewer concisely and completely, then you may not make it.  Get on the phone with a friend or co-worker and have someone go through and ask you questions. Get on skype and use free recording software to record your performance.  Listen to it. Note whether you’re rushed or slow, whether you say ‘um’ and how confident you sound about your skills.

You only get one chance to make a good first impression, and the phone screen is that one chance. Make the most of it.