A few years ago, three co-workers and I decided to work on the concept « hack your job ». We were convinced there was something wrong with recruitment and set out to find a technical solution. We wanted to find a better way to match great developers unable to find interesting jobs with great companies unable to find interesting developers. We concluded this problem required a human solution. Today, I would like to share a potential human solution to improve the recruitment process.
I had some feedback accusing me to try to find a generic solution to hiring. As explained in conclusion, I don’t. My context is a start-up context with highly passionate and motivates people. I don’t claim the proposition I do here is generic, I don’t even claim it’s a good solution, I just assert this is how I would personally try to find great co-workers in my start-up.
I could even write a general disclaimer, I don’t try to teach anything to anybody in any blog article, I just give my feelings and experience.
What’s wrong with recruitment
I think the root cause is our mental bias for judgement. We believe ourselves to be good judges. We actually do it instinctively, anytime we met new people. Fact is: We are very bad at it. Humans are complex creatures. We can’t understand them within a few hours. It is known as the sampling bias. We believe a sample of time with someone will be enough to know if she is a fit for the job.
Daniel Kahneman is the psychologist who wrote Thinking Fast and Slow. In his book, he describes this error very well, because he did it himself. He worked on a team in the army to evaluate new soldiers. Their task was to determine if the soldiers would be good leaders (thus candidates for officer training) or not. They worked really hard to create a comprehensive series of psychologic and physical exercises to determine the soldier’s leadership skills. Tests were run over several days, the team’s confidence in the results they produced was high.
However, after a few years, the feedback they received was disappointing. Few soldiers they recommended for officer training were considered good leaders in the end. And many less recommended soldiers reveal themselves as good leaders.
Jeff Atwood recently wrote an excellent article on the topic. For him, software recruitment is wrong. I strongly agree and will reiterate many of the arguments and solutions from this article, adding my personal understanding and experience.
I see two general approaches to interviews:
Either we conduct an easy and short interview where how a candidate “looks” has a larger role than what they are able to do (not on purpose, but this is how our instincts work).
Or we conduct very long and complex interviews, often in several steps, lead by technical gurus. In this kind of interview, we believe we’re looking for talented people, but actually end up selecting technical clones of the gurus leading the interviews.
I’m not sure which one is the worst. With the first kind, chance is a big factor, but at least we may add diversity in our team. Maybe we won’t hire the best technically, but we will more likely find the disruptive employee with the ability to challenge our work. With the second kind, we will find people fitting our technical needs, while rejecting, more diverse candidates who just did not perform as well during the interview.
Hard interviews do not produce great candidates
They produce great CV writers able to perform well under pressure. Are we hiring engineers for their writing skills? Do we plan to let them work under pressure ? Under pressure we can’t see the big picture, we can’t challenge and improve ourselves. We sense and react to whatever comes next. It’s not a professional behavior.
Removing pressure is the main goal of what I do almost everyday as a software developer. Unit testing, decoupling, context analysis…Whatever I do, I do to improve and manage my work in my context. Understanding our context and mastering the code we produce reduces the pressure we have to support.
How to find great candidates?
A software engineer writes code, with a team to solve business problems. An interview should be exactly that. Instead of simulating stuff, perform a selection based on the developer’s passion, as advised by Sandro Mancuso in his book. Can you find her on Twitter? On GitHub? Can you see some code she wrote? Is she active in local user groups? Any blogs? StackOverflow profile? None of that? Nevermind, take a coffee with her and find clues of her passion. Does she code at night? Any side project? How does she feel about new technologies? Does she realize we developers are changing the world?
As soon as you think you found someone passionate, find a way to work with that person for a few weeks. Jeff Atwood suggests asking them to work at night, or on weekend, or take vacation (if someone does that, it’s a clear sign of passion), and of course, pay them. Consider them as part of the company during this period, so they can really show you how they behave as software engineer. At the end, decide together if they are a good fit or not. You must especially hire them if they are better than you.
How to find great companies?
Be the candidate we want to work with. Recruiters cannot take the whole responsibility for bad hiring processes, candidates must adapt their behaviors too. An interview is a two way process. The company learns about you and you learn about the company.
Show your enthusiasm, give some feedback to recruiters if you think their processes or mails are not that good. Show some respect and passion. Show your interest to understand their problems and how they plan to solve it. Be a Professional, always raise the bar. You can’t wait for the perfect company if you don’t try to be the perfect co-worker.
Hacking the interview
It is certainly not a perfect recruitment process, it is not meant to be. You still have bias, but by increasing the time sampling, you reduce the overall judgement bias and luck factor.
Fighting our biases, as candidate and as recruiters, is one of the hardest and most useful things we can do to improve our hiring process.
Thanks Brian Gibson , Clement Bouillier, Alin Dicu and William Huart for the reviews and feedback.