Interview More Empathetically to Create More Diverse Teams
How we can use UX principles to design a better, more empathetic technical interview experiences
If you’ve been in tech for more than a hot second, you probably know that technical interviews are broken. There’s plenty of arguments floating around about how whiteboarding algorithms and obscure brain teasers aren’t a good indication of a person’s ability to build products. That might be true, but the symptoms of a problem are not the root of a problem. The real issue with technical interviewing today is that we don’t place enough value in diverse skillsets and work philosophies. This lack of understanding is reflected in how we’ve designed and optimized our technical interview experiences to be one-dimensional; they often don’t scratch the surface for skillsets your company might actually need. This approach is the antithesis to building inclusive teams.
A very popular UX mantra is “You are not the user”, and I’d like to introduce the idea of “You are not the candidate”. In the same way that designers and developers can project their beliefs onto their users, interviewers and hiring managers can project their own biases onto their candidates.
It’s been proven many times that unconscious biases lead interviewers to favor others that are similar to themselves. This bias often results is us designing technical interviews designed for ourselves, and goes so far as to suggest we might only accept resumes from people with specific backgrounds. Lately we’ve focused the conversation more on physical traits like gender or race, but we should be equally aware of less tangible attributes like philosophy, thinking/learning style, and life experience.
What can we do differently to address this problem? Here’s an idea: why don’t we aim to create good interview experiences in a similar way that we aim to create good user experiences?
1. Understand the value of both refinement and exploration
Many people subscribe to the IDEO (and Stanford’s) Design Thinking paradigm. The first step of which is Design Exploration, the act of exploring many approaches to a design “problem”. The purpose? To find the best possible solution by exhausting through many possibilities. By living through many potential realities, you can test what the user experience might be like and find the best one, then iterate and refine that best option.
In my opinion, this applies to how some people evolve in their careers as well.
Every person has a different career journey
Not everyone starts off “refined” and goes to a 4-year accredited university for a degree related to their job, has three internships, gets a job in tech, and finds themselves in leadership in 5–10 years. Even if that’s the canonical story, it isn’t even the majority one, and it might not be the best for everyone.
Instead, many people take windy roads, and try many paths and many possibilities before landing in your resume pile. Sometimes those people have landed there as a step in their refinement and iteration journey, and sometimes you’re just another branch in their exploration tree.
There’s a certain graphic that finds its way around LinkedIn every once in a while and I absolutely love it:
Often times, we narrow our top-of-funnel in recruiting because we don’t make space for these windy journeys. We say “5+ years of X experience required” or “4 year degree in Y required” in our job descriptions, and set up all our LinkedIn filters to never look at anything else. This might be required for certain professions, like doctors or lawyers. However, in tech, there are so many learning opportunities outside of formal education systems, whether through bootcamps, online courses, or different roles in the tech sector. Hard requirements on a specific background is often not necessary and that type of thinking is exclusionary to experiences that could benefit our teams.
In my opinion, we can respect differing experiences first by expanding our top-of-funnel, and that starts with our job descriptions. I saw a JD recently that made me smile:
Updating our JDs can affect both who applies to the roles as well as how we think about them. Even if a candidate’s experience isn’t windy, we sometimes will discount them because we have such a narrow view on what we want.
In a previous company I worked for, we interviewed a person with 10 years of experience as a performance engineer for a full stack position. However, our idea of what it meant to be “full stack” was very product-focused and required a 4-year CS degree, which she didn’t have. Worst of all, it discounted her very relevant experiences with simplifying SQL queries, reducing JS bundle sizes, and optimizing APIs to return only what’s needed. Our web application took 5 whole seconds to load and we could have used her expertise, but we were too stubborn and tunnel-visioned to see it at the time. She ended up taking a job at Google. Not only should candidates be allowed to be exploratory, but companies should feel free to be, too.
2. “The journey is just as important as the outcome”
In UX, documenting your process is extremely important. Sometimes, just as important as the implementation itself. The process by which you developed your theories adds to, or questions the validity of, your solutions. It creates the narrative of your product story.
Every person thinks differently
Just like how every person has a different career journey, every person thinks differently, too. In fact, that’s likely why we have different career journeys!
To better accommodate this, don’t design your interviews to only accept a singular path and a singular answer. As much as we’d all like to think of engineering as an exact science, it isn’t; there is rarely a perfect solution in the real world. Instead, most everything comes with trade-offs. When we’re working on product, we’re making compromises all the time while trying to optimize run time performance, compilation time, deployment time, storage space, development time, test coverage, number of server calls, time to first render, and so on. There’s rarely a time when we can maximize all of the aforementioned traits in one fell swoop.
Likewise, when you give an interview, it’s important to evaluate how the person thinks. Coding quickly isn’t the only metric by which to measure a good engineer, but also how well a candidate can identify the trade-offs they had to make in their solution to your coding question, and how open they are to receiving feedback and collaborating on a better solution.
Don’t immediately discount a candidate because they don’t remember how to write bubble sort in one go. Instead, listen to their considerations and concerns as they try to find a solution and determine whether their approach would be an asset on your team. If you’re lucky, they might even consider issues that people on your team often overlook. Our aforementioned performance engineer didn’t finish one of her coding questions, but she pointed out performance inadequacies in the starter code we provided her. That should have been our hint that we should reevaluate our hiring rubric.
3. Give candidates the choice to play to their strengths, but keep the choices limited
A few weeks ago, I asked 400+ engineers what type of pre-onsite interview experience they prefer.
It turns out that most (64%) preferred take home assessments because they felt it played better to their strengths. That being said, the reasons for why people liked one type of interview over another was very telling of how differently people approach problems. It’s clear to me that if your goal is to create an inclusive and balanced team, your interview process should appeal to as many different people as it can, and you can do so by giving candidates the choice of how they’d like to be interviewed.
Achieving this can be done in many ways. Both Patreon and Mailchimp offer the candidate a choice of a couple coding phone screens or a 4–5 hour take home assessment before moving to the onsite interview. Eaze requires that every candidate does a couple phone screens to dive into technical topics (but without coding), then gives the choice to either do a project at home and prepare to present it at a panel during the onsite, or go straight to doing the same project onsite but with an interviewer. One case allows you to work out of the comfort of your home in your own time, resulting in a more abbreviated onsite, the other gives you the opportunity to collaborate and work with another person.
Should we then create an infinite number of interviewing options? Heck no. Not only would that be unsustainable for you, the recruiters and interviewers, but too many choices is also a poor candidate experience. A completely open-ended prompt can cause the candidate to spend too much time on your assessments, and too many interview choices can cause them to have choice paralysis. Don’t forget Hick’s Law, and just be sure to provide just enough choice to demonstrate their ability, but not too many that they are paralyzed.
Aim to appease two or three main groups of people, and develop your interviews around that. In this post-COVID world, that might mean making equally good experiences for those who enjoy working remotely more and those who prefer working in the office more. Or you might slice it by the idea that some people prefer to do their work on their own first, then share their ideas in intervals, while others prefer to work collaboratively with colleagues in pairing sessions from the start. Identify the types of people you may already have and do your own poll to find what works with your work culture.
After years of poor experiences on both sides of the interviewing table, I challenged myself to try to view technical recruiting in a different light. Every engineer I know hates interviewing with a passion, and it feels like every week when I see another article about how broken the system is. When hiring, it’s important to remember that we’re looking to hire the right people for the job, not the right test taking robots or the right pieces of paper. No matter how you look at it, candidate experiences are user experiences, and I bet if we treated them as such, the interview experience will become more enjoyable and we’ll find better matches — for both sides.
