I’ve been in the software industry some time now. I’ve hired a few hundred coders, software engineers or however you want to call them from different backgrounds and experiences. Also from different countries and regions.
Unfortunately I also had to fire a handful of them, most in good terms, some in bad ones. For the latter, I always blame myself on bad hiring practices or profile mismatch. And yet I can say categorically that I don’t have a clue on the proper way to hire software developers. (Which makes nice evening conversations with my wife Laura as a top IT recruiter and HR manager!)
Some time ago, Jeff Atwood wrote extensively about this on Hiring the best engineers. His great article has been rolling around among our circles and shared between hiring managers, developers and CTOs alike.
The key of his article reads in the excerpt:
Only hire the best. The quality of the people that work at your company will be one of the biggest factors in your success – or failure.
Atwood mentions several hiring techniques that, in general are extremely useful. From how to do screen call interviews, to the great idea of an “audition project” (Just keep the developer for a month or so in the office, as a contractor, working on something real). As well as the Bozo Explosion theory. It states that “A” players hire “A+” players, but “B” players hire “C”, “C” hire “D”, which ultimately leads to a company full of bozos.
Well, bullshit.
It is true that good people will always try to hire better people. As an Development manager / CTO I strive to hire developers who are far better coders than myself (which should be easy, given that the last years of my life I’ve been more in politics, management and between excel and powerpoint instead of the command line). The theory of surrounding yourself by great doers in order to create the perfect orchestra. Yet, how do you make the difference between an A, B, C or Z player?
Sure, we all know free riders, lazies, or just people who don’t fit in the company. This tends to happen more and more when a company grows. Your role models can’t spread their wings enough so you need to put processes in place to hire the good fit. But my question is: Would a C player be able to become an A player in a different place, with a different motivation or a different project?
Let’s move ahead a little bit. Coding is fancy now. We are rockstars. Moving from the geek image of Napoleon Dynamite to the hipster cool trendy guy who writes “poetry” code. Bootcamps and academies of coding are on the verge, making good business and launching to the market an army of junior developers. In a lot of cases too junior for the projects at hand. So you have to make sure you hire real good developers, passionate and with experience, who can arrive and start solving problems. Right away.
Companies small and big alike have been improving their recruitment techniques. Coding interviews, technical and psychometric tests, and endless interviews with different departments and current employees. A single opening for a senior Java developer will take you on a journey to meet your (hopefully) future colleagues, your tech lead, your CTO, your product manager, the HR manager and maybe even the CEO of the company. Each one evaluating and questioning every aspect of your debate and your CV. Analyzing your answers, your body language, your confidence and the experience you claim you have. On top of that it is very likely you will have to submit some piece of code to solve a problem, or maybe even do it real time together with your interviewers. All good. Each one of them will have a different perspective of you and your different skills and aptitudes, and then, together, in a kind of Elrond “hiring” committee they will decide whether you are worth to carry the ring to mount destiny. All this assuming that the developer is not bored and left for another company. Guys, remember that we are on a buyers market (for now at least) and even the bad programmers will land a decent coding job. So imagine if you face a good one!.
I’ve met many people with great hiring techniques. In a lot of cases real good engineers and recruiters. People who can read you pretty well. However they tend to fail always in the same thing. Whenever I’m present in a hiring committee everyone is very clear on the skills of the candidate. Strong in Ruby, not so good as DevOps, great with Java or test automation, etc… But then I ask. “What moves this guy?“, “What really motivates him?“, “What he really wants to build or what he does in his free time?“, “How does a career path look for him in our company?“.
Unfortunately in a lot of these cases, they only stay with the skills part. We have become very good at getting the perfect match on the gap between what we need and whether the candidate is technically able to do so (at least given the proper time and money). But we tend to get far away on cultural fit, attitude, willingness to learn and what I call “Sponge effect”. i.e. Capacity of this person to acquire new skills and knowledge in a quick and effective manner. This is specially important in our industry, where requirements, technologies, tools and frameworks change constantly. And the most important one, the one I call “Balls of steel”. Has this person the courage to try new things? To acquire whatever is necessary to achieve his goal? To find the resources anywhere just to launch? This skill is common in entrepreneurs (people raised with the idea of the BBS: Beg Borrow Steal), but not that much in developers who, foor the good or the bad, are used to be taken care, groomed and idolized.
Another common sentence (that I abide with), is “Hire slow, dismiss quick”. This reduces risks, mainly in the latter part, but doesn’t really guarantee you anything. In the end, nothing really guarantees having a good candidate joining your company. So the conclusion would be: “Trust your gut, and take risks”.
– What? Gut feeling in interviews and with people? Are you dumb? – Well, maybe, but honestly I can’t put a proper process in place after many years of experience (and contrasting with better HR professionals) that allows you to not discard false negatives (i.e. Discarding people who are actually valid).
Right, the current recruitment processes I’ve mentioned above are always towards one goal: Avoid false positives. I.e. DO NOT EVER hire people who will not have the skills you need. But only on the technical part. Ends up happening that indeed, you get the qualified professional but suddenly he / she is not an A+ player, it is a B, C, or N player. Is this because of his skills or because you didn’t think properly the team and project the developer would work on?
It doesn’t matter how many hiring frameworks you use, which scorecard, how many processes you put in place. At some point you will have this candidate that the numbers tell you not to hire him. Your brain tells you not to hire him, even your colleagues or your hiring committee tells you not to hire him. Yet you end up handling a hiring letter and that person becomes the fucking best professional you’ve met in a long time.
Is it worth it?