As a hiring manager, as well as someone who has been working in the tech industry for over 20 years, I have spent a lot of time reflecting on my experiences in the interview process, as well as those of the many candidates I’ve either interviewed myself or I am trying to hire. I’ve found that generally, the current state of interview processes — either within tech or outside of it — does not support hiring a diverse workforce.
[photo credit: GOAHEADGIRL]
Interviews rarely reflect what it means to work somewhere.
Interviews, in their current incarnation, hurt diverse candidates because they generally work only for people who are trained well in the process of interviewing, as opposed to those who will succeed in the role itself. This means that candidates from diverse backgrounds (in the case of software interviews, people who did not receive a standard computer science education, for example) are fundamentally ill-prepared and are excluded for reasons that aren’t reflective of their potential and on-job ability.
An example I give in my field involves students from dev bootcamps. If you’ve ever interviewed a dev bootcamp graduate, you’ll find that they’re well-versed on space and time complexity, which is a positive thing in that we tend to ask that question to assess computer science fundamentals. Unpacking that, though — dev bootcamp graduates often learn either a web application or mobile development skill set. Space and time complexity, while important concepts are the focus for engineers who are working on issues around scale and latency, whereby those coding decisions matter because the compiler doesn’t optimize for them; generally, we’d rather have the code be readable and maintainable. This means that dev bootcamps have changed their curriculum to give these non-traditional candidates a better footing in a broken interview process. It’s terrible, to me, that we are putting the onus of succeeding in a broken process on groups of people in that process, as opposed to on those of us who execute it.
We must create relationships from the start with candidates that reflect our relationships as peers or managers.
Ultimately, a hiring manager should be assessing two things: whether or not someone is a fit for their open role, and whether or not that role meets the needs of the candidate. This means that from our first interactions, we are establishing a relationship of trust with a candidate, where we reward engagement in the process with the same level of attention and support we would give someone if they were already on our team. An interviewer should act similarly; this person is likely someone that we will be working with in the future, so we must always treat them with the respect that marks our relationships with anyone else on the team.
We must ask questions that are reflective of the role itself or assess answers to questions outside of this purview through the right lens.
In tech, there is a history of interviews that either ask a candidate to reimplement something that already exists (“reverse a linked list” — not a great question to start with, but also something already available in nearly every implementation of linked lists) or to do an exercise that would rarely be done on the job (asking a front-end candidate to select random information from an endless stream and then do something with it). However, sometimes these questions are unavoidable because asking a person to demonstrate their ability to perform the actual job requires things that are difficult to do during an interview.
If you plan on asking questions of this nature, it’s important to tell the candidate what you’re assessing by asking the question. In the case of the two above, you, of course, know the optimal answer, but having someone respond optimally by rote is much less valuable than assessing how they think through a new problem and develop the answer. Ensuring that you understand what you’re assessing (problem-solving skills, familiarity with core information that is essential as part of the job) and then communicating that to the candidate means that you can defend why what they’re answering is critical to the interview process.
We must set up interview environments to be as reflective as possible of the work environment.
Referring to technical interviews, candidates are often asked to do work in ways that are never the norm on the job. This means running technical screens on things like notepad or coderpad, as opposed to giving a candidate access to a familiar IDE with full advantage of code completion functionality, linters, and integrated debugging tools. This will unnecessarily put them at a disadvantage and often only assesses how they do in this environment, not as an employee.
[photo credit: Tamarcus Brown]
Power differentials between candidates and interviewers are not often successfully navigated by either.
Candidates come to interviews in a position of disempowerment, because those who are assessing them are necessarily going to make a possibly career-impacting decision based on a brief series of conversations. For underrepresented groups, this can be underscored by a pre-existing sense of disempowerment based on societal or social stigma, or worsened by imposter syndrome, which has already been shown to disproportionately impact these people.
This increased level of discomfort will reduce the likelihood that a candidate will perform well during an interview, and means that those who are successful are “confident” as opposed to capable. Additionally, candidates will forget that they are assessing the company, manager, and peers, just as they are being assessed.
We must reduce power dynamics as much as possible throughout the interview process.
The best way to combat these power differentials are, to start, by simply acknowledging them, either actively (saying something about how you know how tense interviews can be) or by proactively adjusting your behavior (being kind and deferential as opposed to stern and strict). Being open to candidates making mistakes, and actively reassuring people who are clearly nervous, goes a long way to establishing a positive long-term rapport as a potential manager/co-worker, and eases the tension that may otherwise keep someone from feeling they can perform their best. (Be careful here to ensure that you’re reading the situation correctly — often, silence may not indicate nervousness, but instead careful consideration, and interrupting to be reassuring can derail thought processes.)
Most interview processes are laden with hidden bias.
We hear about bias often these days, and is the major reason why teams don’t diversify, as it inhibits people from hiring but is subtle enough that it’s often explained away using non-data-driven metrics like “culture fit” or “passion.”
We must actively acknowledge our biases by directly acknowledging that they are innate, pervasive and that they color our interactions with candidates.
Some interesting unconscious biases include:
Similarity bias is often called “like me” bias, and it creates micro-affirmations where we are more likely to hire someone with a similar background to our own. This starts at resume review, often with a recruiter or manager gravitating towards resumes with names that are familiar as opposed to more challenging, but it carries through interview processes with assessments of soft areas like “culture fit.” You can see this play out on teams where people are predominantly from the same parts of the world or are the same gender. To diversify a team in this state, it’s important to start to pull outside of your immediate team during interviews — for example, an all-male team will need to include one female interviewer on their panels and ensure that they hire at least 2 females to the team, to keep that woman from being “the only” woman.
Social comparison bias happens when an interviewer co-mingles the assessment of a candidate’s performance with an internalized assessment of their own level and skill. As we hire higher-level employees, one reason it becomes harder to do so is that it’s often hard for an interviewer to independently view someone else objectively in this situation. An example I used recently was that a higher-level senior engineer might have a hard time advocating for a newly senior engineer, because the interviewer will perform better in their head and see hiring someone else at that level who does less well as a ding, instead of realizing that there is variance in levels.
Anyone can advocate for better processes.
I’ve used these tenets to build hiring processes at small (50), medium (200), and large (10k+ employees) companies, with the outcome being highly performant teams that are strongly self-motivated and effective — but often I had to go the path alone in order to use data and prove that these changes were impactful. The best evidence for the success of more inclusive processes are the teams themselves, which are ultimately more reflective of the global market our companies strive to serve.