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.
Disclaimer (edit)
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.
Military recruitment
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.
Software recruitment
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.
I think that the whole “passion” thing is the biggest bias of them all. If you think about it, it’s biased towards young people with little responsibilities, and low self-esteem. Some people are “only” professional and hard-working, but prefer to do other things during most of their free time. What’s wrong with that?
Then I’ve heard about cases where companies gave a pieces of a project to various candidates as an “interview task”, which was their actual project for the client and didn’t hire anybody (they never had the intention of doing it) – basically getting job done for free. So it’s not a black-and-white issue.
You might be passionate about various aspects of your work, consequently bringing a different perspective to work. Some people like to code all day and not talk to anybody, others love teaching and sharing their knowledge, somebody else loves talking to clients and thanks to that finds out about thing that would break the whole project… Most people are somewhere in between, stronger in one area, weaker in another, unique in their own combination.
I don’t think spending all your free time on programming necessarily makes you the best programmer in the world, sometimes it makes you just… boring and narrow-minded.
I’m half-kidding here, of course, but I really think that talking about “The Passion” is sometimes like nothing more than trying to take the easy way out.
It’s difficult to say who is a good programmer, it’s a complex job, very different in various contexts. In my view it would be more useful to think who would fit and provide most value to the given project/company/team.
That would depend on the context, and would be very different for each environment. In one you want people who are very innovative and challenge status quo, in another you need a skilled “politician” that can sell technical ideas to the management and peers, in other you need good communicators, yet in another a person that can teach less experienced colleagues.
I think very few people think about that before they start hiring and prefer to look for “universally” great people. And I don’t think something like this exists. The same person thrives in one environment and is a “failure” in another.
“As Cockroft humorously pointed out, one Fortune 100 CTO told him that “Netflix has a superstar development team, we don’t!” To which Cockroft responded: Netflix hired them from you, and got out of their way.” (http://readwrite.com/2014/10/06/developers-care-feeding-cloud-open-source/)
Great insights, thanks for sharing.
I also think “passion” is a bias. But I finally accept we’ll be biased anyway, thus I try to find the less worst bias in my context and try to find a solution around it.
I also add a disclaimer because I certainly don’t claim this is a generic solution.
Sure, I don’t think it’s possible to get rid of all biases. And I intentionally tried to play a devil’s advocate here.
We’ve had a lot of those conversations during latest recruitment wave, and my conclusion is that no matter what I expected, it turned out to be waaaay more difficult than I expected 🙂
I think it is true that there are different skillset (e.g., social skills vs technical skill), however I think that passion is very important. If someone loves programming he will simply put more hours in it and spend more time to enrich his knowledge.
Of course a passionate 40 years old with 3 kids is not going to put a crazy amount of his free time in programming. However he/she has probably done that in the past and as consequence he/she has accumulated more experience.
Someone who have learnt Haskell “for fun” is arguably better than someone that just learned one language and the standard libraries used at work and nothing else.
I think it makes a huge difference especially for junior profiles: there is people at the university who have written exclusively programs required to pass the mandatory courses. On the other hand there is people who wrote their small OS for fun when they were 16.
Finally I think that someone genuinely passionate about programming think of it as a means to understand better the world and so he can combine programming with other passions. For example, I was curious about plate-tectonics, so to better understand it I wrote a world generator (https://github.com/Mindwerks/worldengine). In the same way you could study Physics, Maths, Economics etc by using programming as an investigation tool.