Six ways to create an unbiased hiring process

Companies are being lazy.

Their hiring processes are broken, and they’re pointing to headlines and myths as proof of why we can’t have a more fair and representative tech employee base. You hear excuses like: There’s a pipeline problem. The candidates just aren’t at our level. We don’t have a hiring process problem; we’re not perfect but we’re pretty good on this stuff. The competition is so fierce, we can’t focus on anything else.

The trouble is, there’s less of a ‘pipeline problem’ and more of a ‘you’re looking in the wrong places every time’ problem, followed by a ‘your hiring process is broken’ problem. Most organizations also have an ‘asking questions that are irrelevant while creating an experience that both intimidates candidates and fails to test them for the right technical skills’ problem.

Don’t be that company. We can all do better – and we should want to. Why? An unbiased hiring process will allow you to hire better people who deliver better results. You will create a more representative and higher-performing team.

Here are the six changes you need to make to better your hiring process.

Stop drawing from the same well

If you constantly look for candidates from the same source, you will get the same results. Yes, colleges like Stanford and MIT offer great candidates, but they’re trained the same way, they think the same way, and they often act the same way. Whatever products and services you offer will surely be used by a diverse customer set, not just Stanford and MIT-types. And the fastest way to ensure you’re able to develop for a real-world market is to ensure your employees represent it. Period.

So look for self-taught developers with real-world skills, or look to eager bootcamp grads as a way to find new talent to add to your hiring funnel.

Stop using the same few, homogenous devs for your hiring interviews

Start embracing a more representative version of your company during the hiring process itself. It’s simple: make sure your hiring panels are diverse. People’s lived experiences color the way they see the world – and others in it. If everyone on your panel looks the same and has had the same experiences, you lose the benefit of improved decision-making from a more diverse group of interviewers. I’m not talking about adding a token female to the slate because ‘you need a woman’ (yes, I’m speaking from experience here). I’m talking about adding diversity to evaluate the candidates and come to a better decision as a group.

Evaluate actual work, not a logo-filled resume

A resume is the place for big talk; a take-home project is the place where you can walk the walk. A fairer hiring process starts with downgrading the importance of a perfect resume. (Really, what does that look like anyway? Especially in today’s age where you can teach yourself coding skills and languages, and where none of us remember what was taught in the last class of our senior year.)

Evaluate skills and talents by asking for a show of the candidate’s work instead, e.g. with a take-home project. Give them a task to complete on their own – you know, like you’ll do as their manager – and see how they do. As a bonus, it does some automatic weeding out for you: only the serious and interested candidates will invest the time to get it done.

Make your take-homes reasonable and time-bound

Lengthy take-homes – or worse, take-home projects with no time limits – are biased and reward the wrong candidates. First, you might alienate very good candidates who could interpret a long, complex take-home as a way for the company to score some free work (not a good look). Second, you will bias toward people with tons of free time and against people without it (like, for instance, working parents and students). And you may end up hiring the candidate who did well, but completed the take-home incredibly slowly and will therefore be unable to complete a work project in the necessary time. As a rule of thumb, no take-home project should exceed two hours.

Evaluate technical skills, don’t stress test performance

The typical whiteboard interview is a pressure cooker: designed to make candidates sweat as they code on an unresponsive whiteboard while senior developers stare and evaluate them.

But what we’re all trying to get from our technical candidates is how they would perform in the real world. That is not what you’re offering with the standard whiteboard interview setup. But don’t take my word for it: recent research out of NC State bears this out, proving that whiteboard tests measure anxiety, not performance. So, look for a way to give candidates some time to tackle a problem on their own, and then come back in to assess and discuss.

Invest in your own question set

It’s easy to default to a question bank for quick use in your interviews. But you need to create your own set of validated questions to measure the candidates’ skillsets accurately. Make sure you draw on the expertise of people currently doing the work to ensure the questions are right for the job in question.

Doing the hard work of creating your own question sets and relating them to your real roles (as opposed to the boring, generic ‘frontend developer’ questions) creates a huge secondary benefit. You give candidates an experience that’s directly related to the job and a better sense of what they can expect at your company.

Final thoughts

Look, change is hard. I get it. But our tech interviews are riddled with bias and you have to do something differently if you want a better outcome. The good news is that the changes discussed in this article aren’t that difficult to implement. They’re not cost-prohibitive, and collectively, they’ll deliver a hiring experience that’s more aligned with your company, more impressive to candidates, and more effective for you.