First off, I must admit a lot of influence from Steve Yegge on this topic. For me, that was one of those times when you read something and you find yourself constantly thinking "yes exactly, I know what you mean." In other words, it was very consistent with my own experiences and opinions, but better articulated than I had ever been on the topic.
Otherwise my opinions on this matter are partially from my experiences plus a healthy dose of my flavor of logic. I am a big believer in being skeptical when people make statements based on their experiences. This is a common mistake, maybe the most common logical error that people make. Talking about and learning from your experiences is a good thing, but if you want to make a generalization, then you better have a lot of experiences to draw from. That is not even good enough, as your experiences need to be quite varied. Small sample sizes and skewed samples both lead to flawed conclusions.
Ok with all of that out of the way, I think the best approach to hiring developers is to take a very engineering-centric approach. There are things that a (software) engineer does that a scientist does not worry about. An engineer never assumes they will get the best solution on their first try. Instead they plan for mistakes. They plan for ways to measure these mistakes, so they can make adjustments and know if their adjustments are effective. Engineers also plan for failures.
So how does this translate to hiring? First off, you have to realize that a non-trivial fraction of the people you hire will be mistakes. You will get it wrong. In my experience, you get it wrong around 25-50% of the time. That's just my experience, so you should be skeptical about that number. However, it is not the exact number that matters. What matters is that if you think you will rarely get it wrong, that a bad hire is an exceptional event, then you will wind up with a lot of bad developers and it will cripple you.
This assumption can be hard to swallow. A lot of people will just say that this is wrong. However, once you get over this point, then everything else is downhill. If you know that you will make bad hires, then you will instrument your system (in this case your development organization) to check for these events and react to them. You quickly realize that it is key to make this assessment quickly. Do it in three months if you can, six months at worst. Assign a mentor to new hires, carefully pick their first project, whatever. Remember that a new hire is worthless for several months anyways, so the only important thing they can do during that time is prove they are a good hire, not a bad one. If you hire somebody because of an immediate need, you are running your organization poorly -- bring in a hired gun (contractor.) Anyways, it is also very important to make sure the new hire knows that this assessment is going on and that possible results include being laid off or a different position.
So all of this is the end goal, if you will. It is all after the hire. What interest most people is the before the hire process. Again with all of the above in mind, hiring is straightforward.
1.) Attract talent. This is hard. You have to get people to want to work for you. Maybe you hire recruiters. Maybe you use word of mouth. Hopefully you will try to create a good environment and culture for developers. As much as he annoys me, I would still recommend reading Joel Spolsky's ideas on this topic. I think Joel is totally wrong when it comes to the hiring process (actually on most things), but that he gets a lot right when it comes to creating a good environment for developers.
2.) Filter. This is easy. Resumes are the standard result of attracting talent. You can do dumb filtering, like insist on some type of degree, some number of years of experience, some knowledge of a particular technology. Or you can do something more subjective, like look for people who went to certain schools, worked for certain companies, or in certain environments like startups, consulting, enterprise software, whatever. Filtering can get more elaborate. Maybe you have a phone interview and ask some easy questions that you are sure any decent developer will know. Or you send them a similarly easy test of some sort. I am not saying that these are all good ways of filtering, just that they are options.
2a.) But what about traditional interviews? I am not a believer in the traditional, technical interview. It is a huge waste of time. Most people like to give candidates some tough programming or logic problem. Or maybe they go for the open ended design question or puzzle. Here is where I most concur with Stevey Y. All these typical interview techniques do is identify people who think like you. If you are really smart, then maybe this is good, but there is a good chance that you are not really smart. We all think we are smart, it is impossible to be objective about this. Microsoft and Google are both famous for their tough interview questions, but it is ridiculous to think that they are unique in the type of questions they ask of candidates. It is just the opposite. Every software company asks the same kind of questions and they still make a lot of bad hires.
3.) Personality Litmus Test. This is also easy. The one thing you can usually accurately ascertain from an interview is "will I be able to get along with this person?" and "will my team get along with this person?" If the answer is no, then do not hire them. You might think "but it is ok to hire a really smart person, even if they are hard to get along with" but then you are forgetting that you are not very good at determining if a person is smart or not. So just take that out of the equation. Remember the bad apple studies. If you think there is even a shot that somebody is a bad apple, cut the interview short and send them home. Note: I am assuming here that you are not a bad apple, hence that you would not get along with one of these types.
And that's it! If the candidate passes your filters and you think you can work with him/her, then make an offer. Remember that there is a good chance you are getting this wrong, and plan accordingly.
