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.
