Is there any process at a company that is more important than hiring? There are certainly great sole proprietor businesses, but as soon as you decide you want to get more done than what you can do as one person, your ability to succeed is directly tied to your ability to grow the team. You need to find candidates, get them excited about joining you, evaluate them for fit, and onboard them so they can productively contribute.
Perhaps not surprisingly, one of the most critical activities at a company is also one that is really hard! I guess if it was easy, everyone would be doing it. I don’t know about other industries – maybe in mechanical engineering you can go by degrees and certifications? – but in the software startup space, the whole hiring process feels like one huge cargo cult. We take a mix of what we see those around us doing, the processes that we ourselves have been subjected to, and some gut feelings, mix them all together, and dive in hoping it will all be OK.
And you know what? It turns out that at one level this giant cargo cult is kind of OK. Employees get hired, some of them stick around and do great work, and software gets built and sold. And eventually, in some cases, the company gets big and can get all scientific about their hiring process and make sure it hires employees that match just what the organization values.
But at many other levels it is so not OK. Unconscious cognitive biases rule the roost, filtering out those who don’t look/think/act like the interviewers even if those people could add great things to the team. Candidates, even the ones that make it through the process, often come out feeling bruised. Even after a supposed evaluation in the interview, there’s no more than a surface understanding – if that – of a new hire’s capabilities, strengths, and weaknesses when they start. Candidates get very little idea as to whether they’ll enjoy the work they’ll be doing. And at the end of it, it just ends up being so aggravatingly random whether someone will work out!
One aspect of my personality is that I hate situations where I know I’m doing something critically important and that I simultaneously have no idea what I’m doing. And in mid-2015, I had had it with the interviewing process. We’d made some great hires, but it felt like the only reason was a combination of only hiring people I’d worked with closely before – a rapidly vanishing resource – and blind luck (my guardian angel was so busy in the early days of Spreedly). Out of three early hires, I’d already had to terminate one of them. It just wasn’t working.
Cargo culting wasn’t going to work, either. Some of the old staples were total bunk, for instance whiteboard coding exercises which measured for the ability to write code outside of a code editor and put candidates on the spot in a way I couldn’t conscience. Other common practices selected too strongly for things I didn’t value at Spreedly: a pair programming session was out since while I value pairing when it makes sense, I didn’t want only candidates who were already good at it. So I started reading everything I could find, and trying to separate out the “this randomly worked for me” from the “this was a repeatable process that consistently delivered good results, and here’s why.”
That’s when I stumbled across The Hiring Post by Thomas Ptacek, and started to actually take action that felt like it had at least a working hypothesis behind it. The first big step was getting a couple of engineering work samples written, and roping others in to help me run them. As candidates started interacting with the work samples I was able to begin articulating the principles that should guide our hiring process at Spreedly, and we got to the place where it felt like we actually had some rationale for one process over another.
One of the fun parts of implementing work samples has been seeing them spread outside of our engineering group, as sales and support have implemented their own work samples. This proved especially key when we opened up hiring for a full-time remote support person and got absolutely flooded with applicants; the work sample let us focus our time on promising candidates via a blind initial filtering process.
Since getting rolling with work samples we’ve also implemented structured interviews in several departments – making interviewing as consistent for interviewees (and as boring for interviewers) as we can – to try to further drive out bias and do our best to select for qualities that actually matter to the work. We’re not quite ready to write about structured interviews in detail, but once we get a bit more experience under our collective belts we’re excited to share what we’ve learned.
Is our hiring process perfect? Ha! Is it even just decent? Well, it’s at least a lot better than the non-process we had before. But the key thing is that it’s an actual process now with enough structure and results gathering that we can make tweaks and then look at results and have some empirical basis for judging whether it’s “fit for purpose” as we work to build an effective team and organization.
If you’re looking to do hiring right (or at least do it less wrong), here’s what I’d encourage you to focus on:
- Be intentional. Hiring is a super important process with wide-ranging impact to your organizational health. You should not run it on autopilot or just cargo cult off of blog posts or things you saw past workplaces do. Do spend time learning about it – including reading blog posts! – but as you read don’t take in the information uncritically but rather use it to build hypotheses that can be tested. And give special weight to advice that both matches your current organization’s size (“We are not Google” should be a mantra for anyone with less than a few hundred employees) and has clearly been applied and thoughtfully iterated on. Which leads me to:
- Gather data. And give extra weight to articles about hiring that share actual data. Here’s some real data from Spreedly: we’ve hired 10 engineers since we started using technical work samples in March of 2015, and of those 1 did not work out. 3 of those 10 hires were interviewed after we started doing structured interviews, and so far they’re all still here, but it’s a small sample size so far. We changed our applicant tracking system mid-stream (from not really having one to using Lever) so I don’t have exact numbers on how many applicants there have been, but we have graded well over 150 technical work samples so far. More anecdotally, we’ve had generally positive feedback even from candidates who don’t pass the work sample grading criteria, and even the occasional negative feedback has been super constructive, which sets up my final recommendation:
- Iterate. If you’re gathering data, then you’ve got a basic feedback cycle in place, and it behooves you to take advantage of that and continually get better. We’re on the second major version of grading criteria for the first work sample we created, we’ve made improvements to the code that supports it several times, and there’s an issue open for v3 grading criteria. We (by which I mean Ryan, our most excellent Engineering Director) have already done our first retrospective on the new structured interview process and started thinking about how to improve it as well. This is hard work, and it’s messy work – we’re dealing with people, not machines – but it’s very rewarding to see the processes improve and confidence in their efficacy grow.
I hope the impression you walk away with from this article is one of both “it’s a lot of work to do a good job of hiring” combined with, “and we can do a good job at hiring.” One last thought to contemplate: the emphasis on “hiring is a changing process” is not accidental, because the hiring process that works great for us right now at 30 people I know would be totally broken if we tried to use it exactly as-is at 50 people. And that means that “doing hiring right” requires building a learning and growth process for the organization, not finding the static “right set” of hiring practices.
For further insight into how we work here at Spreedly, visit our Engineering Blog.