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.

Today I took a survey on Object Oriented Concepts. Two computer science researchers are trying to determine how divorced the theory they teach is from the day to day practices of professional programmers. Here’s the introduction:

You have done some programming for fun, or you are a professional that has been on one of those $2000 a day professional development courses, or read the latest book, or subscribed to the current in-RSS feed, so you know how you’re supposed to write good code. But do you actually write code the way you’ve been told is The Way, or do you ignore the theory and follow the tried and true practices learned the hard way in the School of Hard Knocks, the way that really works?

We’re researchers. We know what we teach and we know what all the research papers/books say, but you write the code – you know what really works and what’s just so much theory. Here’s your chance to tell us what you know.

If you’re a programmer, you may want to take the survey. I’m sure the researchers would appreciate it.

I’m so enamored with it that I think I’m going to post my answers to each of the groups of questions here, just because I wanted to add more detail and also because I think they’re interesting points of discussion.

What the survey really made me think, though, is that programmer interviews should center more on questions of philosophy. Obviously after an interview you should know whether the person you interviewed can program, but it’s also helpful to know whether you’d actually want to let that person touch your code. I think philosophical questions could extract more information that pertains to both. They also measures the thinking skills of the candidate, and their ability to communicate effectively.

Here’s one of the questions from the survey: “When working on a class, is its depth in the inheritance hierarchy important to you?”

That’s something that someone who thinks about programming could really chew on. If a candidate doesn’t even know where to start on the answer, that tells you something about them immediately. Or perhaps they answer in great detail, but their answer is the opposite of yours, and you don’t find their argument in favor of their side convincing. Do you really want to sit in meetings with this person for the next few years having this same discussion over and over? Do you want them refactoring your code because your way is different than theirs?

After responding to the survey, I want to ask other people these types of questions. They drive right at what’s important in finding good team members.