A Technical Interview Doesn't Have To Suck!

Countless technical interviews are conducted every day that are little more than theatrical self-sabotage for everyone involved. To say that this process is deeply, truly, fundamentally flawed is an understatement. We need to do better.

What kinds of technical interviews am I talking about? The list of offenses is endless: whiteboard tests in pseudocode, hours-long (or days-long!) take-home tests, sorting algorithm questions, FizzBuzz, LeetCode, asking a stranger to write working code in 20 minutes while you stare at them, asking "gotcha" coding questions with a single correct answer, puzzles, riddles, brain teasers... The mind boggles!

Candidates dread interviews like these. Interviewers aren't exactly proud of themselves, either. At least, they really shouldn't be. Technical interviewing has become so dysfunctional that it's better at assessing a candidate's anxiety than their skills.

So, folks, what the hell are we doing? And can we please get our shit together? Read on.

First, An Anecdote

A couple of years ago I was interviewing for an engineering manager role at a local Toronto startup. A part of this interview involved a coding exercise where I was asked to find the intersection of 2 arrays.

While working out the solution using ES6 array methods like filter() and includes() the interviewers suggested I scrap that approach and do it without ES6. OK... I did my best to oblige with some nested for loops. I was then quizzed on the computational cost of both approaches.

Once we finished I asked the interviewers if it was perhaps a style convention of the company to avoid ES6 in favor of hyper-optimized code. I was floored when they told me, "Oh, no, not at all! All of the developers use ES6 freely. We go with whatever works and is fastest for the developer."

We wasted 45 minutes evaluating things that didn't matter! Why was an engineering manager candidate with 20 years of experience writing basic JavaScript code? Why did the interviewers specify constraints that they themselves don't even follow?

Maybe I shouldn't have been that surprised. Throughout my career I've been in many a bad interview:

• I once withdrew from applying at a billion-dollar company when they wanted to schedule a total of 17 hours of interviews!
• I once did a take-home test that I was told would then be discussed with me in our interview—it was never mentioned again and I had to do an additional whiteboard exercise!
• When I interviewed for my first job out of university I was given a written (!) test which I completed in a room alone. I did get the job, though!

Red Flags, Red Flags Everywhere

We know instinctively that the typical technical interview process is a minefield of issues because we've all experienced it. Any one of these problems alone would be toxic enough, but when they're combined it's a disaster.

A Poor Predictor

First of all, many technical interview techniques simply aren't predictive of a candidate's actual job performance. I mean, how could they be?

We can't adequately assess somebody in just an hour or two. To correct for this interviews are starting to get longer. This is, of course, more expensive for the company to do and also sours potential applicants.

Regardless, we're also getting the format wrong. Solving a problem on a whiteboard is indeed a skill, for instance, but as Quincy Larson points out it has "almost nothing to do with modern software development."

Nervous Candidates

Second, candidates are primed to expect difficult interviews and are therefore nervous. This is bad because we’re not interviewing these candidates at their best. Candidates also feel compelled to furiously study or cram for the interview itself and not the job. It's an industry of its very own.

This is because we make them jump through hoops, obsess about the Almighty Whiteboard, give them "fun" (read: narcissistic and sadistic) brain teasers, or push all applicants (junior, senior, or rock star) through the same funnel whether it makes sense or not.

Nothing Like The Actual Job

Third, technical interviews aren't representative of our day-to-day activities or workplace cultures. We wouldn't trust most code cranked out by a coworker in 20 minutes, for instance.

Fortunately, in our day-to-day we have many guardrails in place to mitigate such a thing (e.g., code review, team leads to pair with, user stories with acceptance criteria, etc.). A candidate doesn't have access to those amenities, and the interview is more unfair and adversarial as a result.

Just imagine if a coworker actually implemented a sorting algorithm on company time! We'd rightly question their sanity. They should Google it and then use a library, and that's what we'd advise them to do. Why does the typical interview not do the same?

For candidates, the very format of most interviews can distort and obscure the company's true work culture. We then lose a vital mechanism for assessing them—would we appreciate working with this person?

Most Companies Are Not Big Tech

Fourth, many interview practices aren't a good fit for most companies. We adopt many a "best practice" from the big tech companies—FANG, FAANG, MAMAA, or whatever we're calling them today—whether it's a good idea or not. The same goes for technical interviews.

Google interviews the way they do because they have to do it at scale—that's hiring many tens of thousands of people a year. The vast majority of companies don't have this problem, and for them the approach should be different:

There's an entire cottage industry writing about FAANG's hiring processes. If you're a startup or even a small company, don't give this much credence because likely the decision they made doesn't apply to you. And the decisions they didn't make is because it doesn't scale. This is their weakness and your advantage.

Our Privilege Is Showing

Finally—and this is the most damning—technical interviews can be racist, ableist, or sexist. There's a bias in place for developers who are women, from an underrepresented group, or who have performance anxiety.

Candidates in these categories already have to overcompensate just to be seen as equals. They can be great at what they do but also have to navigate the prejudices of the strangers interviewing them. This can be exhausting or damaging for the candidates and they'll freeze up. Meanwhile, any interviewer unaware of their own bias and privilege will conclude the candidate isn't a good hire.

Why We Hire Determines How We Hire

That is a lot that we're enabling or perpetuating without fully realizing it! To be clear, anybody who's ever conducted an interview has been complicit in this—myself included.

Much about technical interviewing feels correct, to interviewers and candidates alike, even though it's superficial. Developers tend to prefer objectivity, clear outcomes, and subjects that are easily categorized into neat little buckets. So, when it comes to interviewing developers we just want to know if they can write the damn software or not, right?

There are many people who cling to technical interviews because of a belief that many candidates can't write code. Like, at all. As in, it's "disturbing and appalling" and a "slap in the face to anyone who writes software for a living." Clearly these imposters must be stopped! Dan Kegel writes:

A surprisingly large fraction of applicants, even those with masters' degrees and PhDs in computer science, fail during interviews when asked to carry out basic programming tasks. For example, I've personally interviewed graduates who can't answer "Write a loop that counts from 1 to 10" or "What's the number after F in hexadecimal?"

This hasn't been my experience. I'd respectfully disagree and posit that using the interview to test "basic" programming ability isn't a wise use of time. My daily rate is better spent on other activities, but that's just me.

This problem could likely be solved with a phone screen by a recruiter who has a list of rudimentary questions. Instead, we've over-corrected for the problem of assessing competence and aggressively applied that solution to every candidate.

I'm not saying we should do away with coding tests entirely. I wouldn't be so bold as to suggest anything quite so radical. What I would be so bold as to suggest, however, is that maybe we don't need to be so fucking perfect.

For instance, if you're interviewing a junior how much should you truly expect them to know coming in? They're more likely to learn on the job. Your company should provide the space and support for them to grow, and consequently your hiring process should reflect that. If your company doesn't support growth, I might need to write a different essay...

And for seniors, we don't need to thoroughly test their programming ability at a basic level. Their many years' experience, glowing references, or a goddamn conversation with them serves as a reasonable heuristic for that. Do we genuinely think senior applicants are liars and frauds? All of them?

When hiring, the goal is to find valuable additions to your team. That's basically it. As Cher Scarlett rightly points out:

The thing you're looking for, realistically, is the candidate who shows you what you're missing, and that can rarely be figured from a coding exercise, even if it's not done live.

The goal isn't to defend your team from fakers and imposters, or to find the perfect candidate. Doing so only leads to hiring the people that most exactly match your expectations—and your implicit biases. This directly influences the interview format and results in a monoculture within your team.

As hiring managers, we should recognize when we've had a good technical interview when we're surprised by a candidate instead of merely satisfied. Did the candidate tick all of the boxes on your stupid checklist? Or, did you genuinely enjoy meeting them?

Principles For Better Technical Interviews

To foster that kind of serendipity I much prefer to diversify my technical interviewing toolkit by adhering to these 3 high-level principles:

1. Comfort
2. No-code
3. Realism

Comfort

Do what you can at all times to make a candidate comfortable. I can't stress enough how important it is to set expectations and be clear with the candidate about what they're going to experience.

It starts with the invitation to interview. I always indicate who's attending the interview, including their names and titles. I make sure to emphasize that it won't be a whiteboard or live coding exercise. For remote interviews, I strongly suggest the candidate try out our video conference software ahead of time including the camera, microphone, and screen-sharing functionality.

All of this serves to put the candidate at ease as much as possible. A nervous candidate is not a valuable interview because they're not properly equipped to demonstrate their skills and abilities. I'm not just being kind to the candidate, I'm also maximizing the accuracy of the interview.

During the interview I also take steps to put the candidate at ease. This means reminding them that they're doing great, providing psychological safety, or making space for them to take quick mental breaks.

The best way to provide breaks is to split the interview into multiple segments and in between them I ask if they have any questions for me. At the very least I'll allow for a longer amount of time at the end for questions—I'm often surprised how much the candidates' questions reveal about them!

No-code

This essay has really been building up to make this exact point, hasn't it? It's perhaps no surprise, but we've got to stop pinning our all of our hopes on performative coding exercises.

If I only evaluate a candidate's coding abilities then all I know about them is that they can code and little else.

I ultimately don’t care how well someone can simply write code, to be honest. What I do care about: if they're confident in their abilities and aware of their weaknesses, if they show an attention to detail, if they demonstrate problem-solving skills, if they care about the user experience, if they're willing to learn, and so on.

Poorly executed technical interviews don’t assess for these qualities because they're digging in the wrong place. Instead I prefer to rely on realism.

Realism

I like a technical interview to be as close to reality as I can get. This is easier said than done. It means balancing the temptation to inspect a candidate at the finest granularity against the need to see how’d they actually perform in the real world.

I don't want to invigilate a coding exam. I'd much rather look for my next great coworker. I just want to be real and stop with the posturing. We're not inverting binary trees or implementing algorithms from scratch.

All of us look up shit on Google hourly. We talk to our teammates when we're blocked, and help each other get unblocked. We brainstorm problems together and debate possible solutions. We troubleshoot. We apply critical thinking to prioritize work and estimate its effort. And sometimes we throw our hands up in the air and say, "I have no damn clue."

So, I have conversations with candidates on these terms—and I assess their programming ability for free! A candidate will necessarily give me insight into their coding skills over the course of the discussion, and I avoid staring at an IDE and acting as an overpaid human linter.

An additional benefit of realism is that candidates are also evaluating me and my company. Sometimes deliberately so. I need to present the company's culture and ways of working as a differentiator in a vast ocean of coding interviews.

An Interviewer's Toolkit

There are numerous ways to avoid pure coding interviews and their shortcomings. Recall I used the word "toolkit" earlier. I recommend having a variety of interview activities at the ready. To name a few:

1. Present the candidate with a bug to troubleshoot together. This can be staged for the candidate, or an actual bug that nobody on your team has fixed yet.
2. Brainstorm the implementation of a new feature. This can be done with design mockups or with an existing feature of your website or application. The candidate plays the role of a dev on the team while the interviewers are role-playing as product managers and the like. Get the candidate to plot out the work needed, the trade-offs of certain choices, the complexities, and so on.
3. Ask the candidate to open Dev Tools for your website or application and poke around. Let them go wherever their curiosity takes them. The trick to this activity—and what makes it challenging for all involved—is that it's open-ended by design. Take note of what the candidate is drawn to, how they use the tools, how they ask and even answer their own questions, and so on—sometimes they'll even discover a bug! Good candidates can really shine here when they come prepared with notes because they already took a peek before the interview.
4. Give the candidate a mock pull request and ask them to conduct a code review. They can share their screen and go through it line-by-line and either speak or type their commentary. Interviewers may do some role-play as the “author” of the pull request.

For folks used to typical technical interviews, activities like these will be so frustratingly close to coding only to stop short. This is intentional. Sorry, not sorry. Remember the guiding principles are comfort, no-code, and realism.

It's also good advice to mix and match or otherwise tailor the interview to the candidate or the role being filled. Having a pool of interview activities to draw from makes this easier.

Lastly, at the end of any interview I make sure to ask, "What feedback do you have for us about our interview process?"

This question allows me to iterate and improve on how I interview, but also gives me a glimpse into competitors' interview processes. I'm often surprised at how freely candidates will compare the current interview to others they've done, and what they point out will reveal a lot about themselves.

The Only Winning Move Is Not To Play

So, that's how I see things, but it's been hard-earned. We've dug ourselves a very deep hole, as an industry. It's an uphill battle for any individual to improve things just within their own organization.

As hiring managers, we can only hope our companies give us the leeway to improve the process. For myself, I've arrived at these techniques over years. In some of my roles, I've done this in bits and pieces where there have been gaps. In some roles I've even subverted or danced around heavy-handed or prescriptive HR departments...

A good company is one that asks how you as the hiring manager want to handle it and supports your efforts.

For jobseekers and candidates, it's much more challenging to move the needle. How do you point out the absurdity of it all without getting shown the door? There are ways to decline a technical interview that are constructive and you might even come out of it looking smart!

As a jobseeker, if a particular opportunity smells "off" for any reason be prepared to declare that hiring is broken and stand up for yourself. Tell that hiring manager or recruiter why you don't want to participate in their technical interview.

The worst that'll happen is a hiring manager will choose not to move forward. But maybe a polite refusal will make them take notice and accommodate. Better still, if enough of the talent pool makes proper technical interviewing a factor in their job search, the industry will have no choice but to follow suit.

So, demand better! Hiring managers should elevate their candidates. Jobseekers should draw boundaries that both protect their well-being and foster their potential. Perhaps then we'll all meet in the middle and find the process truly works for everyone involved.