Let Them Write Code
This is “Part 2” of a series on hiring excellent talent.
Part 1 was A Talent for Extreme Uncertainty.
I spend a lot of time reading, thinking, and talking with people about hiring. Applicants are anxious. Companies are hesitant. Here’s my conclusion:
We have no fucking idea what we’re doing.
I try to help graduates understand what they can expect in the hiring and interview process, but the real truth is that every company is their own unique snowflake. There are trends and elements that pop up often, but trying to ascribe logic to the approach and process is a fool’s task — which is really ironic for an industry that puts such a high value on logical thinking.
Some companies do everything in one day, some take months. Some do a week of onsite pairing, some ban technical interviews all together. Few companies really understand their cargo-culted process or put in any effort to refine it.
Over the coming weeks I want to explore the elements of a strong technical hiring process, highlight great ideas, and layout a blueprint for better technical hiring.
The arc of our story will include:
- Technical Challenge
- Early Screening
- Technical Interview
- Cultural Interview
- Offer Decision
- Negotiation and Closing
Let’s start with the technical challenge.
Initial Filtering via Technical Challenge
As a company hiring software developers there are three great dangers:
(1) wasting time evaluating wrong fits
(2) hiring the wrong people
(3) missing / never talking to the right people
The majority of resumes that show up at a hiring inbox look pretty similar. At best we can pattern match against people who’ve been successful before and move “hits” to the next step of the process — which is an excellent way to build and sustain a monocultural team.
How do we find the gold in a flood of resumes? By not reading them.
Putting a technical challenge as the first level of the process can eliminate an incredibly large percentage of people. Companies I talk to say that as few as 15% of applicants ever submit a solution to their code challenge.
That other 85%? If you’ve crafted a good technical challenge, that 85% are the ones who don’t have the skills or aren’t really that interested in you. They filter themselves.
The Email Autoresponder
When an applicant sends their resume to email@example.com send them an autoresponse like this:
Thanks for your interest in joining our team. We believe that if you can do the job you should get the job, so our hiring process is based on demonstrating your skill. Visit http://github.com/ourcompany/developer-screening where you’ll find a technical challenge to complete. We hope to meet you soon!
Relatively speaking, no one will do it. Even if the exercise takes just an hour, only 1 out of 5, maybe 1 out of 10 will bother to complete it. You’ve saved yourself from spending any time on the spray-and-pray applicants who actually don’t care about working at your company. Set the inbox to auto-archive all emails for future reference and you’ll never need to look at them.
Working for Free
I regularly see technical challenges that take anywhere from one hour to several days.
The ability to work on an unpaid technical challenge is a privilege. It takes time, effort, and energy that many people don’t have. When you issue a challenge that takes days of effort you’re going to erroneously eliminate people who could be a great fit. Far worse, you demonstrate that your team is the kind of place where unpaid work is the status quo.
What if your technical challenge was intrinsically rewarding? What if your technical challenge helped the applicant polish their technical skills? What if it was fun?
In the next article we’ll look at building a great technical challenge that is valuable for the applicant, achievable in a reasonable period of time, and helps you determine their skill level.
Jeff Casimir is the Executive Director of Turing School of Software & Design. He has never completed a technical challenge because he’s unemployable.