Picture it: you’re a hiring manager for a team of Full-Stack Software Engineers charged with building and maintaining a cloud based CRM solution with a backend written in Python and a React frontend.
Sitting in front of you is a candidate for a new developer position that has recently opened up on your team. They look confident and ready to dive in. You close the door to the office to cancel out the noise from employees playing Beat Saber in the other room, and make yourself comfortable opposite the candidate. There is a large white table between you and the candidate, and an empty whiteboard behind you.
You exchange a few pleasantries, check the time on your phone, then start in with the technical interview.
“Given a sorted integer array, find the k closest elements to target in the array where k and target are given positive integers.” You say, slowly and clearly.
You stand up, pick up a black dry erase marker and write on the whiteboard:
Input: [10, 12, 15, 17, 18, 20, 25], k = 4, target = 16You roll the marker along the table towards the candidate. It slides onto the floor. Oops. It seems like the candidate wasn’t ready for it. You smile and sit down.
“You’ll hopefully recognize this as a binary search question. We ask this in most of our interviews. You can use whatever programming language you want, but we use Python and Typescript on our team, so it’ll be best if you can use one of those. Just roughly sketch it out on the whiteboard if you can.”
To your surprise, the candidate looks immediately flustered. Their relaxed composure has been shattered. They bend down to pick up the marker but then they just sit there, eyes fixated on the whiteboard, not saying a word.
You glance down at their resume which is printed on two sheets of crisp white paper in front of you. It looks really good! Plenty of relevant skills listed, a handful of jobs with interesting experience that seem to overlap quite strongly with the work your team has been doing. And they didn’t use Papyrus font. So what’s the problem? Now the candidate is starting to look really nervous. They’re spinning the marker around on the table while they think, and they’re muttering something under their breath rather than speaking aloud to explain their train of thought.
Should tech hiring managers be using LeetCode and DSA (Data Structures and Algorithms) white-boarding or live coding to test candidates in 2024? In my opinion, no they should not.
Software Engineers are not people who memorize solutions to abstract problems that are not likely to crop up in the actual job function they were hired to perform.
I can safely say, after 20+ years working on software engineering teams, that the best Software Engineers are not people who memorize solutions to abstract problems that are not likely to crop up in the actual job function they were hired to perform.
You win at LeetCode if you can solve puzzle-like challenges such as ‘FizzBuzz’ in your coding language of choice, or if you can provide a concise answer to something like “Given a string s, return the longest palindromic substring in s.”
If you can fire off answers to questions like this you are supposedly demonstrating your ability to tackle complex coding problems and that you understand the necessary math and reasoning involved.
But arguably, the former is just seeing if a candidate knows how to use the modulus operator, and the latter expects the candidate to have memorized the ‘expand around center’ algorithm, which seems like a very esoteric way to test their understanding of memory optimization (or whether they can peel an onion).
When these types of question proliferate through tech hiring practices, it forces candidates to become competitive in the wrong way — they spend so much time studying and trying to ‘win’ the game of LeetCode that they neglect the actual skills and instincts they’ll need to be a successful developer: things like SOLID principles, detecting code smells, best practices for refactoring, and design patterns, to name a few. Even if you land a LeetCode champion for your role, can you be sure that they know how to solve real problems they’ll encounter from day one on the job? You’re looking for candidates who want to level up in their career, but not treating software development as if it’s just a game.
Outside of the big FAANG companies, and any organization that really wants to emulate that elite club, or for roles in embedded systems/IOT, one can enjoy a long and satisfying career in software development without ever being a LeetCode pro.
In 20 years of working in software, I can safely say that, yes, I have used the modulus operator 😊, but I understood why I was using it in the context of the application I was building and why it was necessary, rather than how it applies to some abstract puzzle.
And I’ve always used garbage collected programming languages, so I confess to not really thinking much about memory management outside of common considerations like optimizing for cache hits and avoiding circular references. Call me whatever nerd insult you want, but I earned a nice salary as a software engineer for many, many years having never had to solve these kinds of problems by myself. And I don’t think I am such an outlier.
If a Software Developer ever does hit up against an obscure problem that can’t be solved with their own bag of tricks or a conversation with a teammate, there’s almost certainly going to be a reference guide, a mentor, or an already established solution that they just need to look up and learn when the time comes. Better yet: most of the data structures and algorithms they might try to memorize as a LeetCode gold medalist are already built into the core of the programming languages themselves, or provided by optional frameworks and packages.
Let’s be honest: unless you are recruiting for a very big tech company that needs to hyper optimize or hyper scale beyond the usual constraints of language or hardware — think Google or Amazon AWS — the person you hire is probably going to spend most of their time working with the most common data structures like:
Array
Linked List
Dictionary/Hash map
Queue
All of which can be learned through theoretical and practical means without ever grinding on LeetCode problems for months on end.
As for algorithms, the most common types are used for sorting, and they’ll already be implemented by core methods of the language being used.
And yet many companies still expect candidates to participate in LeetCode whiteboard exercises, even in interviews for basic software development roles where they will likely never need to call upon such specialized knowledge in their day-to-day.
it’s a surefire way to optimize for a kind of competitive elitism
As a manager, or as a highly trained LeetCoder yourself, you may believe this is the best way to ‘prove’ someone is as skilled as they say they are on their resume, but I assure you it’s not — it’s a surefire way to optimize for a kind of competitive elitism that is more a measure of how much a candidate understands computer science and how well they perform under examination-style pressure than how equipped they are for the daily trials of software development. Meanwhile it psychologically crushes many candidates unnecessarily, excluding good people who deserve better.
would you hire a plumber who can instantly recall the scientific formula for water flow rate but can’t demonstrate how to use a pipe wrench?
As hiring managers, we must know how irrelevant such questions are in context of the position we are trying to fill, yet we seem to keep following this urge to test a candidate’s objective intelligence (or rote memorization skills) rather than spending enough time evaluating their subjective real-world problem solving abilities. Which, if you think about it, is quite counterintuitive: would you hire a plumber who can instantly recall the scientific formula for water flow rate but can’t demonstrate how to use a pipe wrench?
And really, we’re hiring a human being for our team, right? We’re not hiring an android that requires instant recall and to be completely unemotional under pressure. The interview should make them sweat a little, sure, not make them wish they could melt into the floor!
That’s not to say that the concepts introduced in LeetCode are worthless or always irrelevant. These are interesting brain teasers and they do reveal details about programmatic thinking that will certainly expand a developer’s mind and improve their mathematical reasoning overall. One could well argue that if the candidate is applying for an advanced Architect or Staff Engineer position they should know more about DSA than your mid-level engineers.
Let’s just stop doing it
But honestly, I’m not going to hold it against a candidate if they’ve never completed more than a handful of LeetCode challenges on their own time and never committed them to memory. If you’re a technical hiring manager, I don’t think you should either. Let’s just stop doing it — unless it is legitimately critical on a practical level for that role.
Back to the interview. You’ve had a change of heart and decided that LeetCode is not appropriate for this interview and is only making the candidate so nervous they will undersell themselves, or worse.
You don’t want to miss out on what could be your next great hire. So you ask them a series of questions that are useful in getting a sense of how they approach problem-solving, how they handle obstacles and setbacks, and what drives them to do their best work, based on the prior experiences listed on their resume.
Additionally, you’ve come prepared with a basic example of some code that the candidate might be expected to work on if they join your team, and some related questions that you can score against a rubric. You open your laptop and ask them to look at the code and talk you through how they think it works while pointing out anything they consider suboptimal or potentially error prone, which is intentionally included in the code as part of the test. The candidate isn’t required to write anything on a whiteboard, you simply prompt them to talk through their thinking process while they examine the code. You build a conversation around this sample of code and really get a good glimpse into how the candidate’s mind works, and their earlier nervousness is gradually replaced replaced with genuine interest and focus on the task.
The candidate before you is a human, not an android, and might just be the perfect choice for the role. And even if they aren’t, they’ll walk away from the interview with a positive experience and a good opinion about you and your company.
That’s worth something too.