“Blink” and the Art of Hiring the Best

What if you could tell, immediately, whether a given person is going to be a great addition to your team? You would be the greatest manager in the history of the world. Thats the promise held out by a careful reading of the book Blink, the Power of Thinking without Thinking, by Malcolm Gladwell.

Hiring the right people is the single most important thing you can do to ensure the success of an IT project. Good people do the right thing, do it fast, and do itwith minimal management intervention. This is especially true in software development, where the good engineers are anecdotally reported to be ten times as productive as the average contributor. I believe this, and I have invested time in recruiting to makes sure Im working with the best people I can find.

I have been working on my recruiting process for years, and some of my methods are rather unorthodox. For instance, I don’t interview developers until I am sure I want to work with them. I couldnt explain why this is important, until I read Blink.

The book shows that it is possible to make good decisions, based on a very small amount of information, as long as it is the RIGHT information.

Over the years I have tried a lot of different ways to qualify potential team members. I havedone interviews, puzzles, calls, chats, code reviews, trials, and reference checks. When I experimented with different methods of qualifying developers, and tracked the outcomes, I was surprised to find that most of these activities were useless. I want to ramp up my teams quickly, and many of these activities added a lot of delay to the process. Even simple Instant Messenger interview added about a week to the typical recruiting cycle. Some of these activities were worse than useless. For instance, if I did a phone or in-person interview, I often ended up liking a particular person, but hiring a bad developer.

Clearly, a lot of these qualification activities give you the wrong information.

Blink gives examples of how you can get the right information and screen out the wrong information literally. One example concerns recruiting players for a symphony orchestra. In the past, most orchestras would invite candidates for an interview, greet them, and then ask them to play an audition piece. But some orchestras now use screened auditions. In a screened audition, the candidate has a number, is not identified, and plays behind a screen. This gave opportunities to a whole new set of players, and resulted in better sounding symphony orchestras.

It turns out that personal interviews tended to result in the hiring affable, good looking men, and lock out some great players who didn’t fit a visual image of what an orchestra player should look like. Without the screen, the personal, visual impression of the candidate is so powerful that it actually affects the sound that the committee heard. They thought they were selecting the best audition player, but when they used the screen, and really were able to listen to the audition, they heard differently. The human mind, your mind and mine, is filled with powerful biases. Some of those biases are useful for making quick decisions, others are just misleading. Its important to manipulate your process to screen out the misleading stuff and get the good stuff.

Another example from Blink shows how you can speed up decisions by collecting less information. Emergency room doctors, when confronted with a person complaining of chest pain, need to decide whether that person is likely to be having a heart attack. They tested two diagnostic methods. In one method, they take three specific measures of heart function and use a statistical algorithm to calculate the likelihood of a heart attack. The other method allowed them take any set of measurements, along with interviews about key risk factors such as weight, age, exercise, and previous heart attacks. In this test, the statistical method with fewer inputs was more accurate. All of the other information, while intuitively relevant, was actually just confusing. And, collecting it caused delays.

So what is the right information? If you are hiring a developer, the best information is a direct test of their ability to work on software. I hire developers for distributed development teams, so it is relatively easy to put them into a trial. I just send some passwords, some documentation, and a trial task. I learn an enormous amount in just a few days by taking their (email) questions and seeing the results of their work. What surprises me is how efficient the trial is and how irrelevant everything else is. I save a lot of time and some money by giving all my qualified candidates a paid trial, even though I am paying for their time before I have screened them.

The best test of a candidate is their performance in the job environment you are hiring them for. The other stuff is distraction. I am trying to figure out ways to apply this trial concept to more job categories.

This type of trial is something that open source projects have been doing for many years. An open source project often has very strict rules about the developers who get commit privileges. If you have commit privileges, you are part of the core team that can modify the code directly, without screening by a project leader. To earn commit privileges, you need to participate in the development project and submit a series of modifications that pass review. So, our inspired by open source development process can give us the answer to a critical business question how to hire the best, quickly. The book Blink explains why its effective.

This article also appeared in IT Managers Journal