Let’s talk about interviewing programmers

Lately, I’ve been interviewing a lot of developers. Not phone screens, but in house interviews that we use to decide whether to hire someone who’s passed the first round. In addition to trying to figure out who the good candidates are, I’m also trying to get better at interviewing.

If you’re getting started with interviewing programmers, there are a couple of must-read articles. The first is Steve Yegge’s article, The Five Essential Phone-Screen Questions. This article is incredibly well-known and I assume everyone has already read it.

The second is Joel Spolsky’s The Guerrilla Guide to Interviewing. He recommends asking an “impossible” question (as anyone who worked at Microsoft probably must). I never ask these kinds of questions. Other than that, I think he’s got it right. You want to know if they can code, if they can design something, and how well they think.

One thing that stands out to me, though, is that none of his questions tell you what kind of team member the candidate will be. This is a major deficiency as far as I’m concerned.

Basically, at the end of an interview, the one question I want answered is, “Will it suck to work with this person?” As Joel points out, it’s important to hire smart people who get things done. It’s also important to hire people who won’t make the people around them miserable. I want to hire people who are flexible enough to adapt to the company culture and open-minded enough to recognize other people’s good ideas. I also want people who are patient enough to bring other people up to speed on their work.

There are a few questions that I’ve settled into asking almost everyone. I don’t worry about people finding me on Google and knowing in advance that I’ll ask these questions because I’d just as soon they come in already knowing the answers.

I almost always lead off with, “Tell me your timeline of programming languages.” I want to know how long they’ve been programming and how many languages and platforms they’ve used in their career. All things considered, I generally prefer programmers who’ve worked extensively with multiple languages. This question is also an easy way to find out which people started programming early in life.

Next, I usually ask them about some experience from their résumé, I’ll pick a project and drill down to find out what the project was, what role they played, and how well they can explain what they worked on.

I then ask them some questions about teamwork. I’ll ask them to tell me something they learned from another developer. Many people talk not about technical concepts but about habits of work, and either sort of answer is fine. If they can’t tell me something that they’ve learned from someone else, that’s a big red flag.

I ask them to tell me something that they’ve changed their mind about when it comes to software development. If you can’t remember changing your mind about anything, you may be too stubborn to work well on a team. It turns out that lots of people have changed their mind about the ternary operator. It’s polarizing.

I will generally ask candidates how they test their own code, to find out what kinds of automated testing they use (or don’t use).

The last question I have started asking almost everyone is to tell me something that they would rewrite if they were given time. It’s a good way to get someone to talk about something they feel strongly about and also to find out what they see as good and bad code. It’s also telling if they want to rewrite something someone else wrote rather than something they wrote.

I’ll also ask a few questions about why they’re looking for a job and what interested them about the company just to get a sense of how interested they are in the position. And of course I ask them if they have any questions for me.

There are three other areas that I think are important to hit, and this is the area where I’m still working on my technique. Those are coding, design, and problem solving. The trick is to fit all of it into the short window that I usually have for the interview. At worst, if multiple people are interviewing the candidate, you should make sure that at least one person will be hitting each of these three areas.

The ideal programming question as far as I’m concerned should be simple enough to solve in a couple of minutes, and be deep enough to have multiple solutions. The best questions have at least a brute force solution and an elegant solution. You can gauge the candidates on which they come up with. I refuse to ask the famous Fibonacci sequence question. There are better alternatives. That said, if you are interviewing for programming jobs, you should be able to write a program that prints the Fibonacci sequence using a loop or using recursion. Someone will ask you to do so.

Design questions are discussed comprehensively in Steve Yegge’s article, which I linked to previously. The goal is to determine whether the candidate understands object-oriented design. The model should be simple enough that you can get past the classes and get into talking about the methods on those classes.

Finally, I think it’s good to ask a question that tests the candidate’s problem solving skills. They should be able to list possible solutions and discuss the pros and cons of each of them. I’m going to write a separate post about this type of question later.

6 thoughts on “Let’s talk about interviewing programmers

  1. Re: “Basically, at the end of an interview, the one question I want answered is, “Will it suck to work with this person?””

    Yes. A thousand times yes. There is at least one fairly week programmer I worked with who probably did amazing things for team productivity because he was so much fun to work with. He was the kind of guy I’d stay after my work was done with to help with his backlog because he helped galvanize the team and made the work environment better. Would I recommend him as a programmer? Not necessarily. Would I want him again on my team? Hell yes.

    There are two types of programming: Technical challenges, and coordinating a team and understanding how the project fits the customer. Programming used to be the former sort of problem, but nowadays it’s really becoming the latter, and that “how do you fit in with the rest of the group” is becoming way more important than “what does your C code to reverse a string look like?”

  2. “It turns out that lots of people have changed their mind about the ternary operator. It’s polarizing.”

    Wait, really? Which way did they change their minds?

  3. My evolution with the ternary operater was like this:

    (~1993-95) “Holy crap, look how cool I can make this one line of code! (~2003) “This ? thing sucks, how the hell do you read all this verilog, guys? (~2005-present) “I will use ? when I feel it’s a good option. I might even go overboard sometimes, but it’s better than a Macro or adding some extra lines of code much of the time.”

  4. I have been doing a lot of interviews in the last six months as well. fwiw, i dont ask much of the way in questions anymore. I make candidates unit test our production code with me. Based on their comfort, ability etc, I can have the candidates test more and more complex code. Usually during the unit testing time we chat about code and projects and technology etc. The benefit is you see who is comfortable with code, with an IDE, with a debugger, etc. You can also see who is comfortable going through our current code and its good/bad patterns/frameworks/etc.

    Way better than asking questions IMO.

  5. I’ve conducted more programming interviews than I can recall, and your questions are great. That said, I find it necessary to give candidates a programming test. I’ve seen it numerous times where candidates can talk technology well but cannot produce when asked. The type of test we give is not a gotcha test, it’s one hat involves real day-to-day type of stuff that they would encounter should they be hired by us. The test has a cutoff time of one hour and a good candidate with a couple years experience should have no trouble with it.

  6. Yeah, I agree that you have to test their basic programming capability. Ideally that’s known before they come in for the face to face. If it’s not, I generally let other people do that interview. I can do it, but it doesn’t interest me as much as digging into the other aspects.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>