Interviews

I’ve interviewed a lot of people looking for jobs at places where I work. I don’t think I’m a particularly good interviewer, but I have developed a few rules of thumb. The purpose of an interview is to see whether somebody can do the job. In my case, the job is programming.

Past experience by itself is not a good guide, as many people can slide through a company without accomplishing very much. Academic experience is also not a good guide, as the experience and goals of programming in an academic setting are very different from working in industry. The ideal way to find out whether somebody can program is to ask them to write a program. Unfortunately, writing a real program takes time, and the interview is time-limited. it would in any case be unfair to candidates to ask them to undertake a serious piece of work in order to get a job. Since most programming is tweaking, maintaining and debugging large existing pieces of software, it would also be good if one could ask a candidate to debug some large program. Unfortunately that too takes time, and it doesn’t allow for the knowledge about a program one would naturally gain on the job. Despite these drawbacks, I do usually ask people to write a short program, simply to verify that they are able to write some kind of code. But I don’t put too much weight on it, unless of course they can’t do it. I’ll add that when writing a program in the stressful interview situation, whether they make any mistakes when writing it is not important, but not being able to see mistakes is a concern.

In any case, I find it more important to know whether they understand the complex layers of software which comprise modern systems. A good programmer understands all the layers of the machine from the processor up to the application. Knowing all the details is not important. But knowing how it fits together is. Here the challenge is distinguishing people who just know the terminology from people who really know how it works. One of the things to look for with these questions is a quick ability to see that they don’t know something, coupled with knowledge of how to find out.

Unfortunately, all the knowledge in the world combined with great programming skills does not mean that the candidate can actually do the job. This gets into much fuzzier areas like whether they can take direction when necessary, whether they can work on their own when appropriate, whether they will make forward progress or get stuck. I don’t know how to figure these things out. The best I can do is ask about their past experiences, and listen closely to the way they talk about things. Are problems ever their own fault, or always the fault of someone else? How long does it take them to accomplish tasks? Have they finished things in the past or always moved on before completion?

A final lesson I’ve learned is that as an interviewer, I don’t have to be fair. Good candidates will find a job somewhere even if they had an off-day when I spoke with them. Hiring the wrong person will be costly every day until they leave. If somebody seems intuitively wrong somehow, then it’s better to trust that intuition than to hire somebody who won’t work out.