You and your hiring process are biased!

Acceptance is the first step to positive change. The problem with bias is that some of us think that we’re immune to it, and thus fail to account for it.  You hear things from hiring managers like, “we’re not willing to lower our standards”, as an excuse for why a team is largely homogenous or, “we let the work speak for itself” – as an example of why this person isn’t biased and doesn’t need to adapt their way of hiring. Both statements hint at a broader, underlying problem of resistance to change and a rationalisation that allows them to not change, when, really, they have already let standards slip, just look at how lacking in diversity your team really is!

Bias, when it does creep in, largely discriminates against under represented groups. We’ve noted five major ways that bias has been creeping into your hiring practices, and how to mitigate them.

 

1. Assumption of Intelligence

According to a study from researchers at MIT and CMU, adding developers with higher IQs to a team does not result in smarter teams. It’s counterintuitive, but it’s a great example of ‘Too many cooks.’

A team which ranks highly in intelligence but  lacks a diverse skill set (particularly in softer skills!) will be less effective than one that has those skills. Ranking developers purely by their intellect results in a much less effective team. You need that balance. More effective teams:

  • Scored well on tests that involved reading complex emotions from faces

  • Had each member contributing roughly equally

  • Had more women in the tea

How about you:

  • Account for soft skills and diverse backgrounds in your testing.

  • Don’t get blinded by hard skills- it’s much easier to upskill a developer in that regard than to develop soft skills.

 

2. The Halo Effect

It’s very easy to get blinded by candidates who are great coders, even if they lack in other areas. The brain works in such a way that when it’s been impressed it’ll downplay any flaws it senses that run against this assumption. This is called The Halo Effect and it’s a kind of confirmation bias. You’ll look for evidence to confirm what you’ve already assumed, that Technically Skilled Developers = Good Fit For the Company.

How about you:

  • Establish several Core Competencies, both technical and otherwise.

  • Have your grading criteria set up before you start getting data from developers. That way you have something concrete to measure against.

3. Looking for Perfection

Going into the hiring process, lots of hiring managers will draw up the perfect engineer that could fill the role. This engineer is almost entirely imaginary, and if you go looking for them, you’ll not find them.

While you should think about what would make a good developer (and in particular, talk to your tech team about what their ideal new team member can do) you should never base your hiring decisions exclusively off of this imagined persona. 

You’ll be setting yourself up for disappointment, unfairly compare great developers to this imaginary one, and end up having to settle for a developer only when you really need one, while all the developers you passed on have moved on.

How about you:

  • Allow for professional development. Truly talented engineers can be trained up to excel. This will also make your workplace even more appealing as a place for personal development.

  • Co create selection criteria with your team. List essential and non essential skills.

  • Allow room for Flex / Growth

  • Take calculated risks and move fast or you’ll lose out.

 

4. The Social Comparison Bias

We all compare ourselves to others, but in the workplace this can quickly get out of hand. Social Comparison Bias is a phenomenon where we start to dislike someone we think is better than us.

This causes resentment, which is not something you want to be feeling towards a potentially very talented developer who would be a great fit for the team. You’ll also avoid giving them the benefit of the doubt, more likely to see them as overconfident or bossy. As with the horns effect, you’ll start looking for reasons to avoid hiring them.

How about you:

  • Try the bar raiser technique or its equivalent.

  • Not everyone can be involved directly in the hiring process, but a second opinion uninfluenced by you can be a pretty powerful counter.

5. The False Positives and Negatives

At a lot of big tech companies, (including Google and Github) there’s been a notable push to ‘avoid false positives.’ In simple terms, this means avoiding hiring developers who will turn out to be bad. The problem is that this results in more false negatives- turning away candidates who turned out to be great. 

Lots of tech companies dismiss this fact as basically harmless. Yet overwhelmingly, the people who face the additional scrutiny that avoiding false positives throws up are people of colour, women and LGBTQ+ people. Hiring managers were not applying this rigour equally, and developers who didn’t match their background were subject to seemingly random rejections.

‘If an entire industry’s interview processes are biased against a particular group of people, members of that group will have a hard time getting hired anywhere.’- Rachel Thomas

False Negatives also contribute to a negative employer brand, especially if your company seems to overwhelmingly reject more diverse developers. This results in a feedback loop where the whole situation gets worse.

Remember: you’re not trying to trick ‘bad’ candidates into revealing themselves, you’re trying to find the great candidates!

How about you:

  • Introduce good hiring processes such as take-home tests, thoughtful interview questions to standardised procedure and reduce the risk of false positives.

  • Track the people you don’t hire and their career paths. Keep an eye out for false negatives, and see if there’s a pattern with people you reject.

  • You can open these communication lines by offering and asking for feedback, which is also a good way to see if there are any problems you’ve missed. Developers know what works and what doesn’t.

  • Get outside opinions. Have someone of a different background check over the material you produce for hiring purposes. 

  • Avoid screening for traits such as ‘culture fit’

Final Thoughts

We’ve offered some quick fixes in this article, but revising your hiring process across the board is the best way to sort bias before it becomes an issue. Bad practice ends with a vicious cycle where your company becomes less and less diverse with no way to fix it. Overhaul your process and you’ll see a wider variety of developers come through your doors.

Your process should be:

  • Data-Driven

  • Consistent

  • Codified

  • Considerate of a wide variety of backgrounds

Nobody wants to think of themselves as biased, but everyone is in some way. By anticipating bias you can adapt for it, and make your hiring process and the industry healthier as a whole 🙂 

If you need help devising or optimising your process, you can reach me at adriano@wearemove.com