Tips on passing the phone screen

If you’ve made it to the phone screen, you’re doing better than *half* the people I look at on a regular basis.  Most fail with their résumé.  Now the tough part: You’ve got to sell me during the phone screen. When I walk out of the phone screen, I’ve got to feel like you’re not going to be a waste of time to bring in for an interview.  You have less than an hour to convince me.

As Sun Tzu once said, know thy enemy.  There are well documented methods to phone screen candidates:

Steve Yegge’s Five Essential Phone Screen Questions:

 

  1. Coding: The candidate has to write some simple code, with correct syntax, in (insert favorite language here)
  2. Object Oriented design: The candidate has to define basic OO concepts, and come up with classes to model a simple problem.
  3. Scripting and regexes: The candidate has to describe how to find the phone numbers in 50,000 HTML pages.
  4. Data structures: The candidate has to demonstrate basic knowledge of the most common data structures.
  5. Bits and bytes: The candidate has to answer simple questions about bits, bytes, and binary numbers.

 

Joel Spolsky’s Phone Screen Questions:

 

  1. Career History: The candidate should be able to describe what they’ve worked on and tell me about themselves. During this part of the process we’re looking for evidence that the candidate is a problem solver, or in Spolsky’s words, someone who “Gets things done.” There are two parts to a candidate’s history that are especially important, Technology and Politics; Technology is what they used to solve their problem. During this part, I’m looking for detailed answers about what they used to solve a problem, and it helps to determine how much of that process they were actually part of.  I had a candidate who had written that they had “Designed and implemented an IM client/server solution for their client.” Turns out the candidate had implemented the user interface for the software, but not any of its innards. Talking about politics with the candidate is really about finding out the story behind where they’ve worked. It’s about parsing the action verbs in the résumé from what they say to what they mean.  In a recent example a candidate talked about pushing unit testing to the entire team. It turns out they didn’t mean automated unit testing, just the testing of a component before throwing it over the wall to QA. I wish I were joking.
  2. Technical problem: It boils down to this: How would you design a data structure of block of code to do X? 
  3. Allowing the candidate to interview me.
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.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s