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.
Misperception
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.
Laziness
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
5 comments:
Largely, I agree with you and am a fan of the craftsmen movement. And I try to focus on practices more than tools when I screen developers, unless there is a very specific need.
To play devil's advocate, it's not always so simple for hiring managers and recruiters. Craftsmen can tend to be prima donnas, and on an existing well-running project, you don't always need a developer who wants to refactor all your nunit/Should tests to mspec, or impose their preferred new architecture.
I've had some success doing the opposite. Taking a team that has a good foundation of modern practices (BDD, CI, Kanban) and introducing developers to the team (less than 30% of team makeup) that don't have that experience, but make it clear to them that they are expected to assimilate to the team and learn those practices.
Sometimes, because of the assertive nature of a lot of the craftsmen movement people I've dealt with, it's easier to go this route, where it's made clear to the developer that they will be primarily learning from the team. In the end, they usually end up teaching the team something too. But they don't enter the project expecting to be the next architect.
Anyway, I mostly agree and support the craftsmen and agile movements. I've just been burned a bit by some of the baggage that comes along.
I agree with what your saying and I see a trend with my clients doing that as well as myself. My favorite clients are the ones who look at the full picture and not do they have this technology or that technology.
I think there are at least two more reasons that 'craft' will continue to be overlooked in the interviewing process.
1) Impatience: A contracting agency always has an eye or two on the revenue stream. Since convincing people that your resources are better, and deserve more $ is difficult even when it is true, the simplest approach is to supply as many contractors as possible, maximizing the total hours billed.
Intentionally raising the bar and reducing the possible number of hours billed with the hope of being recognized for supplying great craftsmen is a long-term approach in an impatient world.
2) Subjectivity: If you ask a dev to give the difference between Comparable and Comparator, his answer will be right or wrong. The questions of craft are harder to construct, as they deal with the larger-scale complexity, and they don't always have one right answer.
A craftsman can tell a craftsman, but to a some managers, the difference is harder to spot.
Often, the problem is that the person to use the technology is needed "now", and the human resource investment is thought of in the short-term.
A lot of agencies and companies try to get around this by having their better devs sit in on the interview. From experience, I can say that the "craftsmen recognize craftsmen" is a crock of ****. We can all be buffaloed by a good salesman when we just have a half hour of interview and aren't focused on the language surrounding a technology. I've sat in an interview with someone who seemed hard working, interested and engaged in programming, but when hired, slipped away from pair programming constantly and sat at their desk instead "checking email" and browsing the web. The person knew all the concepts, and was able to act engaged, but it took more than an interview to separate the craftsmen from the charlatans.
The best mileage we've gotten in interviews has been a question about their computer-hobbiest activities. I have also heard of companies that have a period of pair-programming as part of the interview, though we've not been able to sell this idea to management where I work.
The general public, local government, central government, private businesses and charities so they can source the right information and contacts easily and for free.
Application Developer Facebook
Post a Comment