"The major problems of our work are not so much technological as sociological in nature." -Peopleware, Productive Projects and Teams, Tom DeMarco and Timothy Lister

"The ratio of people to cake is too big." -Office Space, Milton Waddams

Backstory

Recently, I've been asked to help one of our clients recruit better technical staff. Rightly, this organization wants to move some lower-value support we've been doing back into their operation. If done properly, they'll get lower costs and the chance to internalize some core competencies. Of course, we want to help; both because it's the right thing to do, and so that we can focus on more challenging projects.

What makes good developers

Our customer needs "support" developers and analysts. Folks to maintain and extend existing web and database projects, and to perform ad-hoc analyses. One could go on for pages about what makes good staff for these projects. And frequently, job descriptions do.  But what most non-technology companies really need is smart people that can actually get development done. Ideally, these folks:

• are dependable, and can live with and respect deadlines
• communicate professionally, with a good mix of persuasiveness and like-ability
• know how to program very well, with experience in several technologies of the same species as the company standard.

Making Vilfredo Pareto very uncomfortable

The job market for devs is a long shot from being anything even approaching efficient. There are really two factors at work here, and hiring well involves dealing with both of them.

It is well known that the best developers are significantly better than the mediocre ones. And, the more complicated the technology, the bigger this difference becomes. For example, the top web developer at most organizations is probably 5X better than the median developer, whereas for devs doing lower level programming libraries or big database work, the difference probably approaches an order of magnitude.

Despite these differences in productivity, salaries for programmers are nearly flat. While we have a very long tail of talent, we have a standard deviation of less than $20K for most job descriptions. For the astute employer, this presents a huge advantage. We can get 10X the programmer, for 1.2X the cost.

The main reason that the best programmers are underpaid is that it is very difficult to tell who is good and who isn't-especially at hire-time when offers are made. This creates too much risk for most organizations to pay outside the salary band.

Filters

Good programmers that have been around a while will generally be paid more than their lower-performing colleagues. Use this as a first approximation of talent. Because the tendency of most organizations is to hire programmers as cheap as they can get them, you can attract strong candidates simply by announcing your good intentions by posting a high salary. Say, something simple like $nK+, where $n is 20% more than the going rate in your area.

Once you've anted up with a strong compensation package, the next step is to figure out which of the candidates you should hire. Now all of your candidates will look good on paper. They all know every technology that was invented in the last ten years, they all managed a team, and they all "leveraged" something.

That's why it is absolutely insane to use resumes to hire people. Resumes should be used only to determine if someone should be considered for further evaluation.

The only way I know of to determine if someone will be successful as a developer is to have them actually write code. It therefor follows that is is actually impossible for non-technical people to hire good developers. And I think it is here that most organizations fail to succeed. Of course, this doesn't mean managers or HR folks can't be involved-it just means they can't make the decisions.

So, how do you get applicants to write code? We've found that a phone screening process in which we ask the candidate to complete some simple exercises over the phone tends to weed out 80% of candidates. I suspect our phone screening process is about right, because I think this is roughly the number of programmers that can't actually write any code without Visual Studio. Of course, care does need to be taken to avoid false negatives.

If a candidate makes it beyond the phone screen, we're still not close to a hire, but things are starting to get interesting for both us and the candidate. Us, because we could have an excellent addition to the team, and the candidate because good developers like to work at companies with top-notch technical staff, and they're beginning to think they might actually find them here. At this point, we invite our new candidate in to see how we like each other, and to see if they can actually build something. We like to spend a day with the candidate to start, and we have offered to pay some candidates for their time, although I no longer think this is necessary, and may even be awkward.

Field day

We have three goals when a potential recruit comes in. We need to (1) figure out if they can really develop software, (2) figure out if they'll click with the team and (3) make them very interested in working with us should the hire make sense. (2) and (3) pretty much take care of themselves, as long as we structure the day so that the candidate gets to interact with everyone. To figure out (1), we need to construct a project that is simple enough that it can be completed in one day, but complex enough that we can establish a "gradient" across which we can compare candidates. In other words, bad developers can't finish the project, OK developers finish the project, and great developers finish the project "better" than their colleagues who were just OK. Over time, we've developed a specification that developers can code to that involves just that. It is very helpful to keep the spec substantially the same for as long as possible because you'll have more data points to benchmark performance. Because we want this process to be fair, I won't publish the spec here.

We need to make sure we're testing the right things here. Because we want to know how people will perform in real life, we want to make the experience approximates an actual day at the office. This means that we must do everything possible to make the candidate feel welcome and comfortable, to eleviate anxiety where possible, and to provide help when the candidate needs it. The last thing we want is for someone to spend all day navigating a buggy development environment or a trivial technical issue.

Now, the last step in this process is to review the work with the developer. Did they get the project done, did they understand the spec and use time wisely? Did they write good, maintainable code? Involve the candidate in a discussion about how they think they did, and what they might do do differently next time.

The last step is to make decisions. To be sure, this process is time consuming, frustrating, and expensive. But I suspect that is a good thing. Most folks vastly under-invest in recruiting good people, so this is an opportunity for almost any organization to get a leg up. Almost nothing can yield higher returns.