There is no more leveraged activity in building an effective software team than recruiting. The hours or days spent choosing people to add to the team will have a disproportionally large impact on your team’s effectiveness.
If you haven’t already read Joel Spolsky on hiring, you must. Now. The two big ideas I learned from Joel are still the most important ideas in all of my recruiting success…
Joel Big Idea #1
If you cannot answer the “Should we hire this candidate?” question with an enthusiastic “yes,” then it’s a no-hire. There are no “maybes.” The reasoning is simple—a mistaken hire is much more costly than a mistaken no-hire.
I find this principle easy to agree with but difficult to follow. Great developer are always hard to find. The pressure “be reasonable” and hire a maybe candidate has caused me ignore this principle. I’ve regretted it every time.
Joel Big Idea #2
There is a simple rule of thumb to hiring any developer on any team. You are looking for two things: the candidate…
- is smart, and
- gets things done.
Look at the following grid.
You would never intentionally hire Useless, but lets look at two easy hiring mistakes.
Tinkerer: Someone who is smart, but doesn’t get stuff done. This mistake is easy to make because he gives good answers to typical interview questions. However, once you hire him (or her) you find that nothing actually ships. Our industry is full of smart people who are content to learn and write code, but don’t want to commit to finishing something. They never have to deal with customers or operations or any of those messy details because they are always almost done.
Mess Maker: Someone who is not smart, but gets stuff done. This mistake is easy to make because he can tell you all about the projects he has completed. However, once you hire him, you will find that he leaves a trail of messy, fragile code behind him. You will spend more time trying to fix the messes than you gained by having him create them.
The effective developer is the one who is smart enough to appreciate the competing factors and trade-offs that come into play when creating software and is driven to see his solutions solving problems for actual users.
Identifying the smart developers who get things done is no easy task. I’ll have more to say about that in future posts.