in Problems

Preface to Interview Problems for Programmers

It is time to develop a better method for interviewing programmers.

It seems that in the past few months I have read an increasing number of articles about the poverty of technical interview skills. One of the more recent, best, and most direct complaints is this one from Brandon, who runs the blog “Your Startup Sucks, and other happy thoughts.” More familiar is Joel Spolsky’s Guerilla Inteviewing Techniques, which approaches the domain of problem solving, which many people think is what we really should care about.

This section of! is devoted to raising the bar of the usefulness of technical interview questions. Before we begin, let’s be sure we understand the question we are trying to answer, and the game whose rules we are trying to change:

Why do we frequently ask experienced candidates simple questions?

It is a sad first part of the answer that first five years of post-university working life are the time when programmers either become good ones, or they begin their slow movement toward mediocrity and boring jobs. The process is frequently invisible, and that is part of the reason we must ask. Much of interviewing for technical jobs is devoted to the determination of whether a person

  1. has 15 years of cumulative experience, or
  2. the candidate has the same three years of experience five times.

As Joel and Brandon have speculated, it must be virtually useless to quiz candidates on minutæ of programming languages because our workplaces are filled with people who are [a] not very good at their jobs and [b] were able to answer such questions in their interviews. All that can be determined by these methods is whether the candidate has been reading the same blogs that the interviewer reads, and then, only for the past week.

Our alternative is to provide a few examples of the kinds of discussion questions you could ask to probe the problem solving skills of the candidate. We have attempted to present problems that are meaningfully related to what programmers are likely to do, and rather than requiring a definite answer, we want to promote discussion with the interviewer. After all, communication is part of the skill set, yes?

The problems are general, and are closely tied to “the real world.” All of the problems are presented in a similar order:

  1. A description of the problem with all its real world information. If your idea of interviewing is to say one sentence, sit back for fifteen minutes, check your email and watch the candidate squirm in place, this type of problem presentation is not for you. After all, if you want to know how a person solves problems, the questions asked and the dialog will tell you much about the communication skills.
  2. An explanation of what kinds of problem solving skills an answer to this question illuminates. We have seen too many questions that are little more than a test of whether the person can get to the answer; these are different. We have also seen too many questions that test the same skill repeatedly, which might give candidates the wrong opinion that only one skill is required for the job.
  3. A summary of the properties of a good answer. These problems are not about pure correctness. Computer Science often acts as if there were no such things as budget and schedule, but they exist and often rule the solutions space.

Some of the problems we give here have circulated around the Internet or the darker alleys of technical interview circuit in some form, and others have been created by the contributors to!, and various of my friends.

As a preliminary example, we present The Piggy Bank.