Consider this blog post an open plea with hiring managers and recruiters. The vast majority of you focus on the wrong thing when trying to hire developers. Really good developers are exponentially more productive than mediocre ones, but you can’t tell the difference because you are looking at the wrong thing. If you disagree, please ask yourself: “What is the first thing you assess in a candidate when considering them for a project?” I’m sure a few will answer differently but by and large most will say that they are trying to make sure that someone has adequate experience with the technologies in use on the project. I’ve seen hundreds of good, bad and mediocre developers at work and I’m here to tell you that the focus on technical skill should be secondary. Focus instead on hiring developers who embrace quality, take pride in their work, and consistently practice their skill. These developers are craftsmen, not programmers.
Taken at a glance, it doesn’t seem to be a bad thing to focus on technology. Technical skill is mandatory for most development positions. Most hiring managers and recruiters couldn’t fathom bringing someone onto a project written in C# if they professed a novice or rudimentary knowledge of C#. The problem with this mentality however is that there are a number of C# developers who are proficient with the language, yet build very costly systems due to the quality of their code. A developer may know Java inside and out, but it doesn’t mean they know how to build software.
Put yourself in a different mindset, that of a person hiring potential carpenters to construct your new home. If you were interviewing the carpenters would you quiz them continually on their knowledge of a power nailer? No, you’d ask them more appropriately about the differences in constructing load bearing walls from non-load bearing. How to frame a doorway. What procedures they use for ensuring a square corner and flat walls. These questions are all striving to assess what level of quality the carpenter builds into their final product. Why do we not assess the same thing with developers?
I believe it namely boils down to either misperception or laziness.
The main misperception in hiring managers is that technical skill equals speed. It may in fact equate to short term speed, but without an additional focus on quality the legacy codebase quickly becomes a giant time sink that is difficult to change. Studies have shown that the vast percentage of our project costs are in the maintenance phase, not the construction phase, yet how many dollars have been lost by companies emphasize saving time on the 20% at the expense of the 80%? Unless you are constructing throwaway code or something that will be extremely short lived, do not focus on the speed to build. Focus instead on the quality and your overall speed will increase. Focus on your speed and your overall quality will decrease.
I actually think the misperception referenced above is being debunked more and more by hiring managers every day. Sadly though, many recruiters and hiring managers I know are in a rut where they still screen development candidates exactly as they did many years ago. They build simple quizzes to screen for technical knowledge, followed by phone interviews that screen for technical skill and the good ones even follow this up with a programming interview that again determines technical knowledge. Whether it’s ignorance, apathy, or laziness I’m not sure, but if these groups want to see an increase in overall quality (and therefore speed), they need to start asking the difficult questions focused on craft, not technology. I still do a decent number of pairing interviews and I never dictate that someone use a specific language in the interview process. I think my most memorable candidate actually used a language and editor that he wasn’t that familiar with and still you could tell that he had intimate knowledge of TDD and emergent design. I immediately wanted to hire him for any project that we had available and I knew he would be productive and successful regardless of the environment. Can you say the same for the C# developer who has 15 years of experience which are really 1 year projects repeated 15 times?
Craft is not something that is easily learned. K. Anders Ericsson noted that it takes 10,000 hours of targeted practice to reach mastery. If you happen to get one of those passionate developers who have 10,000 hours under their belt, then consider yourself lucky. If you can’t find those people then do the next best thing and hire someone who truly gives a shit and is practicing their craft. You’ll know you’ve found them when they talk much more about quality than technology.
Hammer photo courtesy of thefixer on flickr