A month ago I was scrolling through LinkedIn. I came across a post "How to Hire a Software Developer" authored by a recruiter from a recruiting firm. It had 5 points. I disagreed with 4 of them. Here are my five points:
Don't determine a clear set of requirements - and be very picky.
I was a math major in college. I thought that math was unique in the realm of science. Math people call proofs pretty and beautiful when a theorem is proved in an elegant way. Something about coming to a solution with creativity and brevity elicits emotional reactions. I was wrong, math is not unique. Software developers share in this experience. Code can be beautiful, elegant, or really really ugly. Development is part science, part creativity. When BlueLine Labs goes to recruit a developer we set guidelines to help us filter to the right people, but those are flexible. The correct person for the job is one that mixes knowledge and creativity. Those people don't always have the right amount of experience or the right degree. But they can get stuff done well. That is why we are very picky. We have to reject a lot of candidates that "check the boxes" to find someone that writes gorgeous code.
Figure out your hiring process and keep it personal.
We just hired 2 iOS developers. It took us 5 months. My estimation was that only 100 developers fit our position. There are over 100 open iOS developer positions in Chicago. That is a lot of competition. But you know what? I don't care. We have a hiring process (which should be my next blog post) that can take time and is flexible. The process is based on mutual interest. We need to like the candidate and the candidate needs to like us. Our hope is to keep this developer for a long time. We need to get to know each other - that doesn't happen fast. If a candidate chooses another job, great. We wish them well. We want people who want to work for us. "I used to ask [the candidate] a question, if you had a year left to live would you take this job?" - Brian Chesky, founder of Airbnb.
Change take-home coding challenges.
I used to be a high school math teacher. Most of my students hated doing homework. They didn't hate the concept of work. They hated that it wasn't interesting and didn't add value to their lives. Typical coding challenges ask developers to spend their own time working on imaginary problems. When we hire a developer (or any other position) we contract the candidate to do real work. We get to work with the candidate and the candidate gets to work with us. The candidate gets paid and we get stuff done.
Leave your ego at the door, but maintain your culture.
This is the point I agreed with, mostly. Ego has no place in the hiring process. I want to hire smart developers - hopefully smarter me. We pay what a developer is worth and add tangible incentives (not imaginary equity). But we only want someone who wants us. That isn't ego, that is culture fit.
Make sure that you have a network of developers working for you.
Build relationships. I have done a lot of manual recruiting - sent a lot of emails. I was happy with the response rate, but most developers hate random recruiting emails. I eventually couldn't find any more people to email. That is when I started to meet people and build relationships. I began to refer developers to jobs and be referred to developers looking for jobs. Recruiting got a lot easier and cheaper.