LeetCode-style algorithms in interviews suck. Cut it out.
Interviews that focus on algorithms get false signals and overlook qualified candidates
Modern software development is a spectrum ranging from deep algorithmic work to system design.
The majority of software development happens between that range.
Most developers work on application development, which is closer to system design than it is to low-level algorithms.
Most software development interviews are for jobs somewhere between application development and system design. Yet many interviewers do technical interview rounds only for algorithmic challenges and system design — nothing in between.
The assumption here is that if you can solve algorithms and do system design, you have the skills to develop applications. That assumption is flawed. A broad range of skills is needed to develop applications. You will not get them by just practicing a hundred hours to recognize specific algorithm problem patterns. You also won’t get them by staring at overly simplified systems designs of Netflix, Uber, or Twitter X Threads.
You get application development skills by, well, developing applications. But many technical interviews do not assess those skills.
Algorithm Interviews
For clarity, I’m talking about LeetCode-style algorithmic problems. The majority of algorithmic interviews I’ve done were LeetCode medium and above. They’re often referred to as Data Structures and Algorithms (DSA).
Typically, during an algorithm interview, a candidate is given a problem and is expected to solve and evaluate the solution’s complexity using Big-O notation in less than 30 minutes. Often, the interview is longer, but time is taken up for introductions and other questions.
You’re expected to start by thinking through the problem aloud before writing any code. While solving the problem, you’re expected to explain your reasoning as you go along.
Here are some example problems:
Maximal Square (LeetCode-Medium): Given an
m x nbinarymatrixfilled with0's and1's, find the largest square containing only1's and return its area.Longest Substring Without Repeating Characters (LeetCode-Medium): Given a string
s, find the length of the longest substring without repeating characters.Merge k Sorted Lists (LeetCode-Hard): You are given an array of
klinked-listslists, each linked-list is sorted in ascending order. Merge all the linked-lists into one sorted linked-list and return it.
These problems can be fun to solve when you have time to reason about them. However, in interview scenarios, the time constraint and general pressure of needing to pass to get a job can induce anxiety. To minimize anxiety, candidates prepare by practicing problems to become familiar with the patterns.
The standard advice from books like “Cracking The Coding Interview” (recommended reading by Meta) is to spend several weeks to several months on preparation, depending on your current skill level and familiarity with Data Structures and Algorithms.
LeetCode's “Interview Crash Course” includes 93+ walkthroughs of example problems, 67+ curated practice problems, and 12 quizzes. To get through all this content while you’re also presumably working or otherwise living your life can take months.
This brings me to my next point.
Don't waste a candidate's valuable time
A typical set of interviews includes two algorithm rounds and a system design round. 66% of the technical interview is dedicated to something you will likely code less than 1% of during your entire career.
I've been doing software development for more than two decades. The only time I study algorithms is:
For fun. Difficult challenges can be fun in your free time when no pressure exists.
For an interview.
If they appear in the course of my actual work, I use a (typically built-in) library that is battle tested. Without specializing in that type of work, there is no way I could improve upon them.
Very few people learn algorithmic development on the job. It requires hours of personal time to practice enough of them to be useful in an interview. They are not job relevant for most developers.
Algorithm interviews get false signals
Algorithmic challenges in an interview signal only one thing:
You practiced algorithmic challenges enough to recognize their patterns and solve them.
But, they do not signal general development skills. They signal pattern recognition of specific algorithms and preparation more than they signal problem-solving.
By focusing on a person's ability to solve algorithms under the extreme pressure of the artificial interview environment, you ignore other factors necessary for application development. The biggest being that a candidate can turn business requirements into a solution that solves that business need. Few customers have ever needed you to bubble sort better than another vendor. Besides, AI can already do that better than humans (AlphaDev uncovers up-to 70% faster algorithm for libcc++ sorting library).
In the best case, you find candidates that can productively develop applications. In the nominal case, you find candidates that have studied algorithms well enough to pass the interview. In the worst case, you alienate many candidates that do not perform well with "gotcha" type algorithm questions, such as candidates with neurodivergence.
Alternatives considered
So what should you do instead of using algorithms in interviews?
Create tests more like what you expect the developer to do regularly and which skills are essential for that work.
For example, focus on getting signals for:
Interpreting business needs, functional requirements, and non-functional requirements into efficient solutions.
Breaking down complex projects into manageable tasks and steps.
Application of design patterns.
Use Architecture Principles like Event Driven Design, API First, and Buy vs. Build.
Evaluating what is worth automating (ex: builds and tests in a CI pipeline).
Reviewing code effectively and understanding the benefits of this process.
Comparing tradeoffs between threading and async coroutines for server construction.
Identifying opportunities for performance optimization in code.
Debugging and resolving issues in a given piece of code.
Refactoring code for improved readability and maintainability.
Integrating APIs effectively in software applications.
Unsure of where to start with such a test? Coding Challenges is an excellent resource for challenges that fit these requirements. They're great for interviews or preparing for interviews.
Should I learn algorithms?
Studying algorithms will make you a better overall developer. But that doesn’t mean you need to be good at solving them in under 30 minutes while explaining your thinking. Being able to do that has nothing to do with real word software problems. It’s only useful for the artificial interview environments that are broken and should be changed.
I recommend you learn challenging algorithms when you have free time and are under no pressure to get a new job. The best thing you actually learn from studying them that can be applied to broader areas is Big-O notation and complexity. Understanding Big-O will help you see unneeded complexity in application and system development.
If you’re applying to jobs that have algorithm interviews, then you have two options:
Refuse to do algorithm interviews.
Learn algorithms and practice them in an interview like environment.
Only one of those will give you a chance to get that particular job. If you want that job, do #2.
These interviews are flawed. Unfortunately, if you’re trying to get a job and don’t have the luxury of refusing to do these types of interviews, then you must do them to get the job.
Here’s a list of resources to learn algorithms and Big-O to help you.
Conclusion
I want to see change in the way we do technical interviews. I don’t do these types of problems when I give interviews. My goal is to bring awareness so others will change the way they interview.
If you are giving an interview, consider how you evaluate technical ability. If the job you are interviewing for actually involves working on deep algorithms, absolutely go ahead and test that. If your job is application development or more abstract: cut it out.
Updated
2023/09/09 clarified my stance in “Conclusion” and “Should I learn algorithms?”. Clarified what I mean by “extreme pressure”.
2023/09/08 added “Algorithm Interviews” section and some clarifications (like “async coroutines”) based on feedback from The Primeagen's reaction video.
The best interview's I've done (very senior developer here) have been pair programming interviews. We have a suite of several problems and rotated through them to our candidates. The "problems" are a list of acceptance criteria for a program that we give to the interviewee a criteria at a time and they finish making the program up to the criteria they've seen so far. There usually a couple of difficult changes to the program as new criteria get revealed that need refactoring to achieve or at least careful thought. We sit with the developer and use a style called ping pong pair programming where we go back and forth as driver and navigator every test. The problems are about 5 AC each and can be done it about an hour and a half. We do it tdd style. It doesn't matter if they've never done tdd. It's easy with a guide to do it. Our company actually doesn't do tdd, but we do a fair amount of pair programming. The point of the TDD is to allow collaboration to switch back and forth as driver navigator and have a natural switch between the two. What this interview does is show a lot from entry level to senior level, how do they work, think, collaborate, problem solve as an actual developer. They're encouraged to work as you would work. You can use help/google/talking to the co programmer (the interviewer), just as you would while really working. The interviewer can help interviewees who need it in the form of collaboration. This help gets a lot of nervous people over their nervousness. This interview also reveals quickly if they have no ability to develop (i.e. they can't solve the problems or use the ide). I've had nearly half of the interviewees tell me this was the best interview they've ever been on. After the pair programming exercise we (the interviewer and interviewee) reflect and talk about it. This is where you actually do the senior developer interviewing. Talking about performance, repurcussions, re-use, refactorings, scaling, parallelisms. As you're doing the pair programming exercise, you get an idea and impression of what it would be like to work with the person and what their personality & work habits might be. From the hiring side. Every person I've decided to recommend hiring from this process has turned out to be a great addition to the company. I've never recommended somebody from this interview who quickly left or was a bad fit. I've also only ever heard of one other company doing this kind of interview, which is a shame, because the interview is basically work with me, solve a problem with me, do I, as the interviewer, like working with you and think you can work well in the company. We generally had one interviewer as a pair programmer and one other dev sitting and mostly observing and occasionally helping during the programming part of the interview and all three talked during the reflection part of the interview.
What really happens is you get a ticket that says "Our largest customer wants a report that shows XYZ sorted by the third letter of each users middle name by EOD. Freaking do it now!" This is the algorithm for "Don't waste your time with Big-O nonsense and code something already". This is the real-world scenario you will see most often and the business analysts in your company think of it as O(1).