Such is my life at the moment, I started writing this article on my smartphone whilst commuting home from work. The reason for this? I’m busy at the moment because my team is hiring.
I spend most of my time in the office reviewing CV, speaking to recruiters, headhunting candidates, and, of course, conducting interviews. I’ve written about what I look for in a good CV, so I thought it was only logical to write about the next stage – the technical telephone screen.
The phone screen is usually the first time a candidate gets the chance to speak to one of our engineers. It’s the first impression that they get of the company and potential future colleagues. It’s important that we get it right as the way you conduct the interview says a lot about your company, and the way you work. It’s a competitive market, and if you get it wrong you’ve lost the candidate.
I’ve picked up many tips on interviewing from people throughout my career, most notably at eBay. I think I’ve now got it down to something that works well. What follows is an insight into the way I conduct interviews and some hints of the things I’m looking for.
Preparation for the interview is key. Without it, you won’t have a good conversation, and you won’t know at the end of it whether you want the candidate to continue with your process.
I recently attended the Lead Developer conference in London. At the conference Cate Huston gave a talk about her experiences as a technical interviewer. One of the best pieces of advice from Cate’s talk was to make sure you’re in the right frame of mind before the interview starts. You’re not going to be able to conduct an interview effectively if you’re hungry or stressed. So, I take some time before the interview to prepare myself. If I can, I’ll get away from the desk and clear my mind. Then I’ll take care of the physical stuff. Go to the bathroom; Eat some food; Get some water. All simple things to make sure you’re able to focus on the conversation.
Now that I’m mentally and physically ready, I spend some time planning out the interview. I never expect to follow the plan exactly, but it helps to ensure that I learn everything I need to in order to take the candidate to the next stage. This is key. Throughout the conversation I’m not looking for things to fail the candidate on, but instead enough for me to want to continue. I make sure I have sections on my plan for my key things, technical knowledge, agile engineering, and problem solving.
Onto the interview itself. It should be obvious, but I make sure I’m in a quiet place, free from distractions. I don’t want background disturbances to interrupt my conversation. By interviewing a candidate, you’re asking them to give up a portion of their day, so I respect that and ensure that I make the call on time.
At the start of the interview, I introduce myself and check the candidate was expecting my call. I ask them where they are, and whether it’s still a good time to talk. I don’t want the candidate to be stressed before we’ve even started. I’d rather reschedule the interview if necessary. I also use the answers to check communication – do I need to slow down the way I speak? Is the line ok?
Once that’s all cleared up, I introduce the company. As most people know eBay, I tend to focus on the European Product Development team as that’s who I’m hiring for. I talk about the things we build, and how we build them. The best candidates will pick up on the themes and reference them in their own answers.
Then, I ask the candidate about themselves. How’d they get into programming? What have they been working on recently which makes them proud? Or something recently that they found interesting? During this time, I’ll be listening out for technology, patterns or ways of working. I note down the relevant ones to use as a conversation starter later.
Next up, I ask about their favourite programming languages.
During my interview for eBay, I was asked a rather strange question – “how would you rank yourself out of five for each of the programming languages you know?”. After I was hired, I found out why this question was asked. I was told that the question aims to discover how self-aware a candidate is, and how much they know about the industry or community surrounding a particular language (hint – you’re probably not a 5). To me, it makes perfect sense, and I re-use it in my interviews.
Once I know the candidates favourite programming language, I continue with some technical questions based on it. Usually it’s in a language I know fairly well, so I can make a judge whether the person on the other end of the line knows their stuff. However, as well as knowing the intricacies of their favourite programming language, I’m listening to how well they explain concepts to me. The key thing with this section is for the interview to retain it’s conversation feel. I don’t want to turn it into a Java pop-quiz.
From here, I move onto a couple of questions around data-structures. It’s fairly easy to guide the conversation from the programming language specifics to generic data-structures. For example if we’re talking about Javascript, I use dictionaries as a segue. This is the computer science theoretical part of the interview. Most candidates are digging deep in their memories for this stuff, and I’m therefore not too bothered whether they can quote the big-O notation for a binary tree perfectly. However, I do expect candidates to be able to compare data-structure efficiency, and demonstrate that they know when to use which one.
This typically leads onto a conversation about scaling, so I add a few questions around building products at scale, listening for real world examples. Loose coupling and services are usually mentioned at this point, so I also do a quick check in on the candidate’s knowledge of REST. Examples from things that the candidate has built always beats theory.
At this point, I’m about two-thirds through the interview and I’ve covered enough to be satisfied that the person knows how to program in their favourite language. This is the what of the interview – what do they know? Next is the how – How do they build software?
This is the part of the interview where I go deep on agile engineering and XP. Asking a candidate to give a 30 second elevator pitch helps me understand whether they understand the core concepts. For better or worse, I’ve found that most of these pitches focus on the application of Scrum. Would you describe Scrum if you only had 30 seconds to tell someone about agile development?
I will then steer the conversation towards testing. This is an important part of the interview for me as it’s something our teams value highly. I ask about TDD, and then extend this to testing in general. I don’t want to hear that a candidate throws their products over the fence to QA to test. A conversation about dependencies, will usually follow, leading us to clean code principles, SOLID and refactoring.
If I’m not sure about the culture fit from what I’ve heard up to this point, I throw in a couple of behavioural questions. By this time, I should have enough to go on. It might seem to be a lot of topics, but it’s really just a discussion about how the candidate builds software.
Hopefully, the candidate will feel like the interview has been a conversation, rather than an interrogation. To finish, I open up the line to the candidate to ask any questions they have. I’m happy for anything, and I’m honest in my answers. I end the call by thanking the candidate for their time (really important), and letting them know when they can expect feedback.
I find it easier to collate my thoughts directly after the call. I review my notes and scrub anything where I don’t have clear evidence. Just having a feeling about something isn’t a good enough reason to reject a candidate. Here’s where the planning comes in handy. As you knew what themes you wanted to talk about, you should know whether the candidate did enough in each area.
Once I’ve completed the feedback, I then make a decision as to whether I want to see more of the candidate’s code. Feedback is then given to the candidate and the process continues. There’s probably a whole other blog post on writing and giving good feedback.
That’s it. There’s my process.
Getting the telephone interview right is critical to hiring great talent. Make a mess of it, and everyone ends up disappointed. It should feel like a natural conversation, however, as the interviewer you need to ensure that you get enough information to find out whether the candidate is smart and can get things done.
I’d be interested to hear of other people’s experiences of being on either side of the interview.
Thoughts on Engineering Management 