How to Hire a Software Developer: The Phone Interview
Dec 1 2008Note: This is part of a series on hiring software developers. See articles tagged with interview for the series.
The Phone Interview
The purpose of the phone interview is twofold. First, a simple baseline for communication is established. Communication is the most important quality a candidate can have. You can always learn new technology, but if you can’t communicate clearly- your ideas, your work, and your ability- you probably won’t work well in a collaborative environment. Secondly, the phone interview provides a benchmark for technical ability. This is usually a list of straightforward programming questions in the particular language most important to the job. I use this list of .NET questions to get a sense of surface area and depth.
Communication
How do you know a candidate is a good communicator? A two prong approach works best: first, have them go over their resume. Ask about the projects they’ve worked on, and what they did on those projects. How good are their answers? Do you have an understanding of the work they did? Did they ramble on too much, or not provide enough depth, or repeat themselves? If you asked any questions did they give a direct answer?
Second, find out how well they answer technical questions. This isn’t an issue of right and wrong, it’s about complexity. Did they provide a clear explanation of the answer? Were they concise and confident they knew what they were talking about? Was there a hint of ego in their response? The more you phone interview the more you can tell someone who is good or bad at communication. It’s that “thing†that makes you say, “Tell me more!â€
Technical Questions
There are plenty of sites out there for programming type questions- whether C#, PHP, Java, etc. You know the technology you work with- so ask the candidate if they know it too. Be flexible on this, we often interview people without any knowledge of the programming language we use. If you’re an expert in one language, you can probably pick up another pretty well. Try and figure out how well the candidate has dug into their craft. This will also give you the opportunity to rank a candidate as junior, mid-level, or senior. It also lets you know how much they’ve hyped up their ability (if you have the audacity to list php, .NET, java, perl, cobol and fortan as your “expert languages”, I’m calling you out on it).
Break up technical questions into a standard set of categories. This includes SQL/Database work, class design/architecture, web programming, web services, html, javascript, language/framework how-to’s. Go in with more than you can possibly fit into the allotted time: this will allow you to maneuver during the technical interview. It doesn’t make any sense to ask a candidate who has no sql experience a bunch of sql questions. Instead, focus on their stronger skills or go for more surface area.
How many questions to ask? That’s easy: ask until they get something wrong. This is important, because it allows you to see how they handle themselves when they don’t know something. They’ll either flat out admit they don’t know it, make an educated guess (hint: they’ll have a good sense of reasoning skills), or lie. I prefer going for surface area then depth. First, find out how much they know about different things. Second, pick some of the most important areas you’re looking for and go for depth: see how much they know in that area.
Here are some questions I use for the phone interview, or the in house interview if needed. Note, I’m not going for detailed how-to’s. I like to keep things high level, as I believe it’s important to know concepts. Google will tell me how to expire cache after ten minutes.
Divide and Conquer
Usually, the phone interview is handed out to a lot of different people, as it’s somewhat time consuming and very hit or miss. Some prefer to have one person do the phone interview so they can easily compare candidates to make it to the next round. Either way, it’s important to make a checklist. A checklist lets you remember the differences between candidates, and allows other developers to easily summarize their phone interviews. I’ve gotten a lot of blank stares and “How do I do this?†after asking developers to do phone interviews. Give them a set of questions- and a checklist for them to fill out- will make your and their lives easier. If you can’t into trouble (i.e. sued) for not bringing somebody in, a checklist will also give you cover.
Conclusion
The most important thing for you to know is don’t worry about ending the interview early. If clearly you don’t like them, you just say any number of things:
1) “I’m sorry; we’re looking for someone with more experience. Thank you for applying.â€
2) “Thank you for your time. Unfortunately, we won’t be able to move forward.â€
3) If you want to postpone the face to face, there’s always “We’re in the process of interviewing candidates now and will let you know about the next round in XX days.†Then, e-mail them no in XX days. This works if someone else is doing the phone interview, or you want to mull it over. Giving them an e-mail date prevents them from living in limbo when you’ll get back to them. It’s simple respect.
You can even add in “We’ll keep your resume on file†if you feel guilty. My point is, be respectful: if you know they’re a no, don’t waste their time or yours.
How do you decide you makes it or who doesn’t? Simple: if they impress you and you want to know more, invite them in. Your gut check should be, “This person has potential.†If not, don’t move forward. If you’re on the fence, put them on hold until you seriously would want to hire them. Don’t bring them in for the sake of bringing them in- the in house interview should take some time, and if you’re not serious about them, don’t have them put on a suit, take time away from their current job/life, and make them travel just to use as a benchmark for something else. It’s not right.
Ideally, 15% of your applicant pool you want to do a phone interview with. Maybe 25% if you are in a tight technical market like NYC.