Hiring help

Common sense says the latter. Yet the typical interview goes easy on the candidate. In this article, I’ll show why that tactic doesn’t work—and I’ll give you an alternative approach that does.

The classic interview
In the typical scenario, interviewers start by asking candidates to recap their resume. Then come inquiries about specific projects they’ve worked on and which languages and protocols they understand. Candidates who spout the right buzzwords and acronyms with a certain air of authority tend to convince interviewers they know enough to perform the job. Typically, candidates will repeat this conversation with two or three people, gaining confidence with each interview that they’re answering the questions correctly and will be offered a job.

Frankly, I think that this is one of the worst ways to interview candidates for a software development position. Most of these positions are high-stress, deadline-oriented, bug-fixing endless loops. Developers are always scrambling to meet a project or product delivery. This is why software deadlines are never on Friday, always on Monday—so that we have the weekend just in case we need it. Given the stress of a job like this, why do we persist in giving candidates a kind and gentle interview?

What you're trying to learn
The goals of an interview are simple: At the end of an interview, you need to know whether:

• The candidate is actually competent in the required skills.
• Sufficient chemistry exists between the candidate and the rest of the team.
• The stress of the job will break the individual.
• The candidate can think clearly about problems and work toward solutions.

Although these goals seem obvious, the typical interview doesn’t accomplish them. No amount of buzzwords and acronyms will prove that a candidate can withstand the pressures of a software development project. Instead, you need to take a more rigorous approach.

The progressive interview
Over the years, I’ve developed an approach I call the “progressive interview.” A progressive interview starts with two scheduled interviewers; additional interviewers are added to the schedule if the candidate shows promise. (More on that topic below.)

Because the interview process is progressive and interviews may be added, all candidates are asked to set aside four to six hours. Every candidate will spend a minimum of three hours in interviews (two with interviewers plus one with a human resources manager), and the system doesn’t work if the candidate is in a rush.

Each interviewer will have an hour with the candidate—sufficient time to accomplish a great deal. Here’s how that hour breaks down:

• Recap the individual’s career and resume for about 10 minutes. Discuss the highlights and ask any questions about odd gaps, interesting projects, etc. Ask about the candidate’s goals and objectives. If the candidate claims to be familiar with a protocol or tool, ask a specific question to validate the claim.
• Test the individual for about 40 minutes. This is the most critical element of the process. Each interviewer should come prepared with a problem for the candidate to solve. The problem should be selected or designed in such a way that it encourages discussion. The goal is to find out how the candidate solves problems and reacts to the stress of a software development job. Asking him or her to solve a problem does just that.
• Wrap up by answering the candidate’s questions for about 10 minutes. This is a standard tool, but it’s a nice way to conclude the hour. It will generally calm the candidate down a bit after being surprised with a problem-solving session and prepare the individual for the next interviewer.

Testing the candidate
The test is the heart of the interview, so it’s crucial to do it right. I’m not one for written tests—I prefer the whiteboard test. Hand the candidate a marker, describe the problem, and watch him or her solve it. The problems I give are usually incomplete, so the candidate won’t be able to solve the problem unless he or she asks a few intelligent questions.

My favorite problem for senior developers is the memory manager. Given that memory in a heap is modeled as a list of free blocks and memory offsets, write a malloc() routine that allocates memory from a free list. This is a very straightforward coding problem wrapped in the guise of system-level programming; the problem statement is designed in such a way that the candidate has to see through it to realise that the solution is not that complicated.

This classic problem has all of the elements of a good test. It requires the candidate to decide how the free list is constructed (array or linked list?), where the free list might exist (as a global variable?), and which algorithm is used to select a free block (first fit? best fit? worst fit?). In addition, it gives the candidate and the interviewer a great deal to talk about.

The candidate can write the code in the language of his or her choice. Generally, I don’t care much about syntax errors in the code—that’s really not the point of the test. I want to see if the candidate can think on his or her feet and respond to the pressure of a problem.

Here’s another good problem to pose:
#define swap(a,b) { a = b; b = a; }

It’s simple but effective. Simply ask what the macro does, whether or not it works, and how to fix the code so it does work. I usually use this problem along with another one, such as asking the candidate to output a binary tree in prefix, postfix, and infix order.

Obviously, the problem you pose should match the candidate and the position. Give design and debug problems to senior architects and designers; give code challenges to top developers. Sometimes, you can use logic problems to achieve the same goals.

Deciding whether to add interviewers
As I mentioned earlier, two interviewers are the minimum—two opinions are necessary to decide whether the candidate is a match. If the decision is inconclusive, I’ll generally send the candidate to a third interviewer and then make a decision.

After each interview, I caucus with the interviewers. (If a face-to-face meeting isn’t practical, each interviewer should send his or her opinion in an e-mail.) The discussion is brief—each interviewer provides an opinion about whether the candidate shows enough promise to add more interviewers. If so, we do it immediately; if not, we end the series of interviews rather than waste additional time.

How the interviewers handle it
Admittedly, this isn’t the easiest interview to conduct. The interviewer needs to be well prepared and comfortable asking a candidate to solve a problem. And interviewers need to feel confident that they’ll be able to understand whatever solution the candidate proposes. That means problems posed should match the skill and experience level of the engineer posing it.

Not incidentally, the interviewers who’ll be most comfortable using this approach are those who went through it when they were hired. Use this technique consistently, and sooner or later your team will find it second nature.

How the candidates react
Candidates have reacted in a variety of ways to this interview approach. Some have refused to participate; they were thanked and sent on their way. A candidate who’s too good to demonstrate his or her competency doesn’t belong on my team.

Some candidates have collapsed under the pressure and have even failed to begin to work the problem. In that case, I’ll see if I can get the person started with the problem to help them overcome the shock of the situation. Occasionally, the pressure was too great, and the individual couldn’t muster an attempt at a solution. When that happens, I usually send the candidate on his or her way as well. The pressures of the situation are not unlike a challenging, deadline-driven debug session, so the candidate’s reaction speaks volumes about his or her ability to handle the job.

This approach does more than reveal how a candidate responds under pressure. It’s also an excellent way to gauge the chemistry between the candidate and existing team members. Because the interviewers are usually potential coworkers, watching a candidate solve a problem gives the interviewer insight into how they might work together. Is the candidate arrogant? Confident in his or her abilities? Comfortable asking questions? Does the candidate explain the solution as he or she is solving it?

Conclusion
While this approach may seem tough, I have been phenomenally pleased with the results. The developers I’ve hired using this approach have stayed with the company longer and have been more productive than those that didn’t go through the process. Most of the developers that got past the interview process were eager to accept a job offer. They knew they’d passed muster and were excited to join a group of developers who were also up to the challenge.