I’m tired of your interview process. I’ve worked in tech on Linux and Windows based servers since 2003 — and I was doing it for fun before that. I installed Slackware off of repurposed Windows 95 beta floppies. I remember when you had to recompile the kernel to raise the number of file descriptors.

Does having been around since the 1.x kernel days mean I shouldn’t have to prove my abilities? No, but your half-baked interview processes don’t actually clarify a candidate’s abilities and I’m tired of performing interview theater. As an industry, we have managed to create the perfect process to ensure that corporate cultures stagnate and that the employee base of a company takes as long as possible to diversify.

On top of the damage this does to a company and its ability to adapt, these outdated and inaccessible interview methods disproportionately hurt the chances of neurodivergent candidates and other groups that tend to not perform well in the same environment a checkbox person might.

Here are some things we need to move on from in favor of more effective ways of measuring someone’s potential for a role:

Mandatory/Default Live Coding Exercises

HackerRank, CoderPad, Leetcode, and other similar methods of doing live coding exercises need to be drastically scaled back. Nobody should be required to do a live coding exercise as part of an interview. It should be at most one of a number of options that attempt to assess the problem solving and programming ability of a candidate. Take-home quizzes are dramatically less anxiety-inducing for a lot of people (myself included). A live coding exercise often has little to do with what the candidate’s output is like on the job. Instead, they are much more of a measure of the candidate’s anxiety and comfort level in the interview room than their technical ability, and many of us already have a therapist to tell us how anxious we are.

Why are you giving Senior Engineers coding interviews anyway? Do you really think someone who has been holding increasingly more demanding jobs over the past decade or two was faking knowing Python the whole time? I’m sure that has happened, but this is an area where we can apply Occam’s Razor and say that if someone has made it this far in tech, they can probably write a couple of nested for loops (and, honestly, if they can’t they can definitely Google it).

For junior engineers, this is actually a harder problem I think. Junior engineers are less likely to have a GitHub full of sample code or a long list of prior experiences, and it can be valuable to see how someone who is newer thinks about a coding problem. So offer a choice. You want to see that someone can write (a script, a program, an algorithm). If that someone is jazzed to do that in a coderpad session with you, cool. Do that. If they aren’t, you should offer them something else. There are a lot of great engineers who can’t confidently do anything in a Hackerank tab with someone watching. If you are interested in measuring someone’s confidence: Don’t do that? How confident someone is during an interview with strangers and how confident they are working among their peers in a job they already have are not the same thing.

Code interviews of any kind should also be later in the process than they generally are. Making everyone who applies for a job commit to several hours of unpaid coding for a problem that you might never actually want to interview them over is just offloading the burden on to people who are already in a tough situation. Don’t do live coding interviews, definitely don’t exclusively do live code interviews, and absolutely don’t do code interviews until you’re like 75% sure you’re going to hire the person.

Trivia & Minutiae

I pretty regularly get asked for things like “name some Linux [syscalls]” or “what are some Linux [signals]”. I’ve got a better question: “Who cares?”

Should someone applying for a DevOps or SRE position know what syscalls and signals are? Sure. Does everyone need to commit all of them perfectly to memory? No. My ADHD ensures that I won’t remember a lot of things, but I will almost always remember how to find something — either because I know where to look now or because I wrote the thing down in my copious plain text notes. Memorizing a list of things only serves to measure how well a candidate memorizes lists. If memorizing lists is critical to the position, by all means do it — but I suspect it isn’t.

Aside from the gotcha nature of “do you remember this thing you had to look up for one incident you worked in 2011 and never again since?” type questions, they manage to exclude candidates for a bad answer while not actually telling the interviewer anything useful in the event of a positive answer. If you are asking a question in an interview, you should be attempting to learn something about the candidate and their experience. Learn about how they think, about how they learn. Why bother asking a question that tests someone’s ability to retain information for 12–24 hours?

Asking the Right Questions

“How do you interview candidates for something you yourself aren’t an expert in?”. A good interviewer doesn’t need to know the answer to the questions that they ask to know whether or not an answer was good. They might need to evaluate an answer for correctness, but when you’re asking questions to evaluate someone’s practical experience in an area, some of the best questions prompt that person to talk about whatever they want.

If you ask me “how does a packet get from your phone to a server” I’m going to give you a pretty vague answer, because I’m not going to study like I’m cramming for a Network+ exam this far into my career. If you say to me “tell me about a time you dealt with an unusual networking problem and how you resolved it” I’m going to tell you a way more detailed and interesting story about Dell Optiplex 2×0 boxes that all had the same MAC address when their Service Tag was cleared. If you ask me “what order does the kernel do things in when it boots up?” I’m not going to know because it does those things and I only remember the ones I’ve had to care about in the last few years. If you say to me “Tell me about a time you ran into a kernel bug, and what you did to track it down and resolve it?” I’m going to talk to you about a bunch of NFS servers in Europe that were rebooting in the order they were deployed after 497.1 days.

Not everyone is going to have these stories — especially more junior folks or people switching careers. You should have enough awareness of that (from their resume/other questions you’ve asked/etc.) to tailor your questions accordingly. If you are asking the same questions of an associate engineer candidate that you would a staff engineer, you’re doing one or both groups (and probably your company/team) a disservice.

Empathy

Probably the biggest thing missing from these scenarios is empathy.

Everyone has horror stories about candidates having a meltdown during an interview, or disappearing between sessions. These stories usually get brought up as funny anecdotes between colleagues talking about interviews they’ve given. Why is this viewed as some kind of harmless anecdote, rather than a tremendous failure on the part of whoever was facilitating those interviews?

Looking for a job is stressful. If you are interviewing someone who is already out of work and looking for new employment, there is a tremendously imbalanced power dynamic — especially if there are other factors (years of experience, checkboxes, etc.) that make a candidate less confident in an interview. The imbalance is essentially unavoidable — you can’t have the newest person at your company interview the next candidate in perpetuity.

So how else can you control for it? Developing your sense of empathy (empathy is a muscle that can be exercised — and if you don’t think empathy has a place in engineering, you are very much part of the problem) is a critical part of interviewing candidates (and being a person). You were not born with an innate knowledge of systems engineering or programming or whatever it is you’re interviewing someone about, so remember what it felt like walking into a room with a couple of people who have had the job you want for a decade or more. Put yourself in that position and think about what you’d want in that situation — or even just ask them! I would accept an offer almost on the spot from a company where I was asked what accommodations might help me be more successful before or during the interview.

Unconscious Biases

There has been an enormous amount written about unconscious bias in the workplace and I am by no means an expert on how to combat it. All I’ve done is make sure that I took unconscious bias training when offered it, took it seriously, and tried to combat it within myself and the processes I controlled when I was able to. I am also confident that I have not done enough. Read up on it, try to understand it, and think about how it might affect you when you’re interviewing a candidate who isn’t quite like yourself.

Does the candidate have trouble maintaining eye contact? Do they seem nervous? Do they jumble their words? Do they repeat themselves or skip thoughts? Do they have trouble keeping verbal statements in order? What do these indicate to you, consciously, and do you feel like your prior associations with those behaviors might influence what they tell you in an interview?

I don’t think I’ve ever met anyone who thinks they are performing at their peak when interviewing. Expecting that of a candidate changes the focus from finding candidates who are capable of doing the work needed, to one of finding candidates that are most confident in interviews. Interviewing well and performing well do not have a strong correlation in many cases.

Also, I implore you: never, ever say something like the following quote from a recruiter:

“We have everybody go through the same interview process to eliminate bias”

-A Tech Recruiter

I can’t tell you how many times I’ve heard this sentiment, which is the recruiting equivalent of this:

Treating everyone the same does not eliminate bias, it just cements a certain kind of bias: a bias towards conformity with the existing culture and the existing employee base of a team/company/organization.

No Alarms and No Surprises

One of the most common things — and this isn’t surprising considering the interview panels I’ve been part of (on both sides of the table) — is just a painful lack of followthrough on commitments that are made during the process. If you tell a candidate you’re going to interview them on Linux Kernel internals, and then it is actually a coding exercise or something else totally unrelated, that candidate is going to be on the defensive immediately. A bait and switch might seem like a fun psychological experiment but it doesn’t belong in an interview.

The goal here should be to make a candidate as comfortable as you’d hope they would be working for your company day to day. Give them a schedule, stick to that schedule, and if forced to deviate from the schedule either reschedule it or give the candidate some time to prepare for the changes. If your interview process is chaotic, candidates are going to (rightfully) think that your day to day operations are also chaotic.

What Can Be Done?

The answer to this depends a lot on your relative experience and power. If you’re a brand new candidate in the industry, trying to get their first break — I’m so, so sorry. Especially if you’re a part of one or more marginalized groups. I can’t promise it will definitely get better, but I do promise there are those of us who are trying our best.

If you’ve got years or decades of experience under your belt, though — or if you’re a hiring manager, or a recruiter, or someone in recruiting leadership — there may be a lot you can do. First, give feedback on the process — regardless of if you get an offer or not (and whether or not you accept that offer), you should let the recruiter know how you felt about the process.

Say No

I cannot stress this enough: if people with decades of experience in the industry don’t speak up about this, it will take much longer to fix the problem. Use your privilege, however much you have, to make things better for those who follow you. You do not have to accept the parts of the process that made you suffer as inevitable for those that follow.

I am very good at what I do, and when I’m not in the middle of an anxiety inducing interview nightmare, I am very confident in my abilities. So from now on, I’m not only not going to do the parts of the interview process that I find ineffective, biased, and anxiety inducing — but if I get a job at a place that does use those methods, I’m going to do everything in my power to make sure that process is modernized and rethought to consider the impact these interview methods have on diverse candidates.

So no more live coding exercises, no more pop quizzes, no more trivia. Have a conversation, engineer (or manager) to engineer with me where I’ll tell you what I know and what I can do. We can shoot the shit about Hadoop or Kafka or Kernels or crontabs or wherever the conversation takes us — and you will learn way more about me than you would quizzing me on something that I could find the answer to on cyberciti.biz.

Your Experiences

I’d love to hear from more folks in marginalized communities about the kind of things they’ve encountered that they suspect (or know) someone who checks more boxes wouldn’t have had to deal with. Feel free to reply to this thread on Twitter (or just DM me), I’d love to hear from you.

For people involved in implementing these processes who would like to help make this better: I’d love to speak to you about it as well. Feel free to get in touch via Twitter or LinkedIn.