Inclusion in Tech: 5 Keys to Consistency in Your Tech Hiring

Improving Diversity is an important goal for most technical teams across industries. But data suggests that leaders are missing the mark. In the US alone, a survey conducted by Wiley found that 50% of technology workers have left or wanted to leave their job because of the non-inclusive company culture and 68% of business leaders felt that there is a lack of Diversity in their workforce. Organizations around the globe spend millions on Diversity and Inclusion efforts and have pledged to recruit more team members that represent a variety of backgrounds, not just the most privileged. However, a pledge and financial investment are not enough to level the playing field and hire diverse technical teams.

In this blog, I will discuss five meaningful ways you can impact diversity on your team, by first improving Inclusion in the hiring process.

Why do Diversity and Inclusion efforts in tech often fail?

First, let’s step back and look at why so many Diversity and Inclusion efforts in technical hiring often fail. Lack of standardization in coding skills tests, technical interviews, and criteria for making hiring decisions creates room for bias. This is unfortunately very common in large organizations with different team members participating in the hiring process. Consistency in the technical hiring process will ensure that you are objectively evaluating the only variable that matters—the candidate. It is the piece of the puzzle that will help you develop inclusive hiring processes and, ultimately, diverse technical teams.

How to improve Diversity and Inclusion in tech hiring

      1. Make job descriptions inclusive and relevant

• Use inclusive language. Job descriptions should be the roadmap for success. Making them as inclusive as possible, by using fair language, that appeals broadly to software engineers of all backgrounds is important. Work with your team to make the job descriptions as relevant as possible.
• Identify what success on the job looks like and make that your north star. What is the software engineer responsible for? What kind of tech stack will they be working in? What do they need to achieve immediately vs. what can be learned on the job? In a role that evolves as much as developer roles do, carefully consider what can be learned on the job and do not expect candidates to come with that knowledge.
• Separate behavioral competencies from technical skills in the job description. In most software engineering roles, a keen understanding of data structures and algorithms may be key to success. But consider how important it is for a new hire to work with other team members. Can they have code review discussions? Can they debate their approaches? Those skills that develop work dynamics are important, but often do not make it onto the job description or into the assessment process.

All of the above will help teams design relevant hiring processes that keep great candidates in, without unintentionally filtering them out at the first step—the job description

2. Leverage pre-configured coding skills tests

Variability in coding skills tests can harm your primary goal–assessing the coding skills of the candidate. By introducing custom questions, or allowing teams to introduce their own questions, different variables are introduced…and some could result in bias. Instead, consider how you can calibrate the score to your hiring bar while using pre-configured coding skills tests. These tests have some advantages—you can immediately tell how long they will take, which skills they are designed to assess, and plan for the questions you will use in the technical interview. Hint: they will match the same competencies and come from a similar question bank. 

For bonus points, use tests that have been reviewed and validated by I/O psych experts. This can ensure that your coding skills test accurately assesses logical correctness, programming ability, and adherence to programming best practices while reducing adverse impact.

3. Leverage pre-configured technical interview questions

Just like coding skills tests, interviewers ought to use pre-configured questions that reflect only the most important competencies and skills in the role and use them consistently. This consistency ensures, once again, that the variable evaluated is the candidate—and nothing else. It is unfortunately common for software engineering interviews to rely on the interviewer to come up with the questions—and they may not be shared across other interviewers or used repeatedly for the same role. This can introduce an inconsistency in the process, which also means bias can creep in. Pre-configured technical interview questions also reduce the cognitive load on the interviewer. In a world where software engineers may be conducting 5 – 10 interviews per week – or maybe part of a dedicated interviewing team—reducing the burden on these team members is important. That way they can put their focus back on the candidate.

Pre-configured technical interview questions ought to have scoring rubrics mapped to them. These will identify the behaviors or skills you expect the candidate to demonstrate. More on this later!

Consistency is the piece of the puzzle that will help you develop inclusive hiring processes and, ultimately, diverse technical teams.

4. Compare hiring funnel metrics for different candidate cohorts

Inclusive hiring processes measure the pass rates and onsite to offer rates of candidates by gender, race, geographic location, and other factors. This allows teams to verify that all have an equal shot of success. In university recruiting, start by measuring success by the school. For experienced hiring, branch out into measuring success by geographic location or by the previous company. Measure pass-through rates to determine if some candidate segments are failing more often than others. Likewise, measure onsite to offer ratio to see if some segments—women, for example—are not receiving offers as often as their male counterparts, so there is likely bias in the process. How will you get this data? It does need to be supplied by the candidates on their own. In the US for example, Equal Employment Opportunity Commission (EEOC) surveys can supply this information to your ATS.

5. Making hiring decisions using scoring rubrics

Scoring rubrics sound scarier than they really are. It has been common for teams to subjectively rank candidates on a 1 to 5 scale. Sometimes referred to as the “Yelp review.” The problem here is that this is subjective. One hiring manager’s 2 may be another’s 4. The task of the scoring rubric is to change the subjective rating to an objective one. How? Scoring rubrics should be done for each assessment, each interview question, and for the overall hiring decision. This helps keep teams accountable to focusing on what’s important in the role as opposed to what’s a “nice to have”, or a biased interpretation of a score. Below is an example of a scoring rubric for programming ability. Notice that each score is a skill level, for which there is a very clear definition.

And finally, bring it all back to the job description. Does your job description realistically mirror the skill level and the skills you will objectively want to identify in your assessment and interview process? Closing the loop will help keep the team honest.

Improving diversity and inclusion in tech hiring has been a challenge for many leaders, and it is worth the effort. Inclusion is the key to building diverse technical teams, both in the assessment and in the culture. Consistency ensures that the only variable in the hiring process is the candidate, and they can be assessed objectively. Maintaining consistency throughout your hiring process is the first step to achieving Inclusion.

SHL Technology Hiring includes coding skills tests, technology and framework, multiple-choice questions, and a technical interviewing platform needed to establish consistent and fair technical hiring processes. Book a demo with one of our experts today!