Before I was a software engineer, I was an actor. I went to school for theater, and spent the first five or six years of my professional career having the majority of my interview process center around auditioning. Basically, I’d go into a room with a casting director, and do a 2 minute snippet from a prepared monologue or two. Sometimes I would sing and dance (literally, if it were a musical). Sometimes I’d be in the room, waiting to audition, while other actors also auditioned in front of me for the same roles. Auditioning sucked, it was never something I looked forward to, and yet.. I would prefer it pretty much any day of the week over a technical interview.

I’ve been asking myself recently why that is. I really, really didn’t like auditioning, but there was a part of the process where it at least felt like the job. One of my mentors always told me to think of auditioning as a chance to just get to perform for any audience of one, and while simplistic, there was a part of that advice that took the evaluatory aspect out of the process and made it a conversation between me and the director – much like an actual performance. In my experience, with technical interviews, that just ain’t the case.

Here’s my typical technical interview experience: I may (or may not) have material to prepare for, depending on the type of exercise. I may (or may not) be able to ask questions of my interviewers. I’ll usually have some sort of time limit, and that time limit often includes the mental bandwidth needed to properly understand the problem space I’m being asked to code for/answer. My interviewer will often say “Please feel free to ask any questions that come up”, but that would require quickly getting to a stage where I can cogently ask useful questions, which itself takes time. The interviewer will then watch me as I code/flounder, nervous as all hell, trying to both problem solve and perform my competency at the same time. Then, if I’m lucky, I’ll get some feedback on how it went, but most likely, I’ll get additional questions about various aspects of the exercise I missed or could refactor.

And of course, I’m being a bit dramatic about the above. Technical interviews run the gamut, and some organizations do them very well. But in all honesty, as I progress further in my career and have begun to do as many technical interviews as auditions, the fact still stands: I find the prospect of technical interviewing to be dreadful, and the execution usually bears that dread out. I’ve done them before (successfully and woefully) and I’m sure I’ll be forced to do more in the future, but even thinking about having to go through a theoretical technical interviewing process makes me feel a bit nauseous. And here’s the thing: I usually love the other parts of the interview! I love meeting potential team members, telling them about experiences I’ve had, and learning about what they do. I just hate that moment when the shift switches from a dialogue to a gauntlet.

So why is this the case? And am I alone in this? Certainly a portion of it stems from an inferiority complex about this career path that lurks ever present in the corner of my consciousness (hi inferiority complex, I see you lurking there!). But being an engineering manager, I can see the same dread manifest in the software engineers I’ve interviewed for my team. The feedback I get from candidates when doing a round-up at the end of the process confirms this: it’s a terrifying prospect. And my wife, who is a far more brilliant software engineer than I, has recently gone through a series of interviews where she felt the same thing. Even the best technical assessment of the bunch left her feeling drained, judged, and (most egregiously to me as a hiring manager), like she didn’t even have an opportunity to authentically express the qualities that make her an exceptional candidate. And there’s the rub for me in this process, when I think about how it compares to my auditioning experience: at least with auditioning, I felt I could accurately portray what it was that you would get out of me if I were cast in the show. With technical interviewing, I often feel like I don’t even get a chance to manifest the things that would make me qualify for the job in the first place. I don’t get to show technical interviewers “me”, I have to show them an answer to a problem they are trying to solve.

What to do about it? There’s a lot of people much smarter than me with much richer backlogs of knowledge that I’m sure grapple with this question. To me, it is a fundamentally problematic component of this career path – one that has implications on equity, inclusivity, fairness, and opportunity in the industry writ large. Obviously this is a technical career. Obviously we need to assess the technical aspects of the job. But how do we do it so that it doesn’t suck so much? Here’s some ways I think about it in the interviews I’ve had to conduct:

  1. Make it a conversation, not an evaluation. This is quite hard to do, but try to avoid questions that have pre-determined answers. What is the point of asking an interviewee a question that has an answer that can be Googled? Instead, talk with your candidate about experiences they’ve had in the past, and how those experiences relate to the job. If you are interviewing someone to work on databases, instead of “What’s the difference between SQL vs NoSQL?” try “We tend to use SQL databases here because our data looks like X. Can you talk about choices you’ve made in the past between using SQL vs NoSQL?”
  2. Prep the room. This may seem extremely overly done, but I find it is important. If you are in a conference room, don’t place your candidate sitting facing everyone like a jury. Circle up around them, like you would in a meeting where someone was sharing a cool new developer tool. Vocally clear the air: “Listen, we know this can be nerve wracking. But we want to make sure you feel comfortable, and get a chance to shine. We totally get the nerves, and that you aren’t working at 100%, and that’s okay - just keep talking to us about your thought process, that’s the most important thing!”. Create physical and emotional space for this fellow human being to do something that is daunting
  3. Make the technical assessment resemble the actual job the person will actually job, as close as possible. If you are interviewing a front end developer who is going to be working on a new UI, send them a design mock to review and have them jot down some questions about implementation details. Then, have the designer “update the mocks”, and ask the developer to do a bit of coding on how they’d adapt their work to the changing specs. Maybe even ask the designer to come along to the session! What’s extra nice about this is that the candidate gets a sense of the all important question: “what would it actually, truly, actually be like to work here?”

Finally, and most importantly, consciously and willfully practice empathy in the room. Model it to your co-workers who are there with you. Assume that this person is competent, and worthy. Make them feel welcome, and excited even. This is going to be a friend, a colleague, a trusted conspirator. Treat them as such.