What sort of things can you learn when interviewing someone for a technical position? What questions are useful?
This is a much-discussed and sometimes hotly debated topic in the tech world. I’ve done a fair bit of interviewing for my employer over the past few years. We’ve built an excellent technical team, either because or in spite of the interviews I’ve done.
Here’s my unsubstantiated theory about interviews and what they’re good for. (My personal opinion, not my employer’s!)
First of all, I know all about the research that says that interviews don’t predict performance for technical positions. I agree 100%. This is why we give candidates some sort of technical homework before scheduling an interview. We expect this to take no more than a few (2-3) hours at most. We review this homework before we decide whether or not to continue with the interview process. I weight this fairly heavily in the process, and I’ve rejected candidates simply based on reviewing their homework submission.
But the interview is still important. Here are some of the things I think I can learn from the interview, and some of the questions I use to figure those things out.
Does the candidate actually want this particular job? Enthusiasm matters. I’m not looking for a cheerleader, but I also don’t want someone who’d be happy with absolutely any job. One question I might ask to get a sense of this would be “What appeals to you about this position?” I can also get a sense of this based on the questions that the candidate asks me.
Is this position a good fit for this particular candidate? I want to make sure that the candidate has a clear understanding of the position, specifically their work duties, time requirements, expectations, etc. Some questions along these lines would be “What are the most important things for you in a position?” and “What do you need from the rest of the company in order to do your best work?” If someone says that the most important thing is working on mobile apps written in Haskell and we don’t do that (because no one does), then that’s a good reason not to hire them!
Can they telecommute and/or work with telecommuters effectively? Most of our team is remote, so even if a team member works at the office, they are effectively telecommuting. I just want to be sure that they either have experience with telecommuting or some idea of what this entails. If they haven’t done it before, do they have a work space that they can use? Do they have a plan for dealing with the challenges of working at home?
Can the candidate communicate effectively? Are they pleasant to talk to? Some people are not good communicators. Sometimes two people just don’t mesh well and rub each other the wrong way. Maybe I interview someone and just don’t enjoy talking to them. This doesn’t mean they’re a bad person or bad at their job, but it does mean that we shouldn’t work together.
Can they communicate effectively about technical topics? One question I’ve asked people is simply “What is OO?” There are many right answers to this question, but the real goal is to make sure that they can communicate about a technical topic clearly. If someone doesn’t know any of the terminology around OO (“class”, “instance”, “attribute/field/slot”, etc.) then it’s going to be hard to provide code review on OO code. Note that some people can write code well and still not be able to communicate about it.
Can they communicate effectively with non-technical people? For most positions I’ve hired for, our expectation is that the person being hired will be working not just with the engineering team, but also with a product manager, sales and marketing, support, etc. I want to make sure that the candidate can communicate with these people. We do a short role-playing exercise where one of the interviewers pretends to be a non-technical customer asking them to build a specific product. Then we have them ask the interviewer questions to get a sense of the product requirements, constraints, etc.
Do they care about technical stuff? I want people who actually have opinions about doing their job well. I may ask them what tools they like and dislike, what they’d change about the tools they’ve used, etc. On the flip side, I don’t want someone who’s dogmatically opinionated either. (Or at the least, no more dogmatically opinionated than I am.)
Do they ask good questions? I expect candidates to come to the interview with questions of their own. If they don’t ask any, that’s a red flag that makes me wonder if they don’t care about their work environment, work process, etc. This does not make for an engaged coworker.
There are also things I don’t look for in an interview.
Cultural fit. What is this? I have no idea. It’s way too broad and an easy excuse to simply reject people for not being enough like me.
Code-writing skill. That was already covered by the homework. I never ask specific technical questions unless I have a good reason to believe that the candidate knows about the topic. I might think that based on something specific in their cover letter or resume, or better yet based on their homework or FOSS work.
Will they work out long term? You can’t really answer this confidently from a short interview. What you can do is screen for obvious red flags that indicate that this person will not work well with the team you have, or that they will not like this position. In the latter case, I hope that this is a mutual decision. In my own job searches, I’ve had interviews where I came out knowing I didn’t want the job, and I consider those interviews quite successful!
Will any of this guarantee that I will always find the best people? No, obviously not. Hiring is a difficult thing to do. But if you consider the goals of the interview carefully, you can make the best use of that time to improve your chances of finding the right people.