5 reasons to ban leetcode questions from interviews

Today coding challenges are the bread and butter of software engineering interviews. They are also known as leetcode problems, from the name of a popular platform that provides an interactive tool to test candidates. They consist of a broad range of standardized questions that should be answered on the spot and within a limited timeframe: generally, they only have one "correct" answer, that requires the application of very specific data structures or algorithms.

Despite their popularity, I believe that they are not a good selection tool for companies and have an overall negative impact on the industry. These are the 5 reasons I think we should get rid of leetcode.

1) Prowess in coding challenges doesn't reflect real job skills

Interviews should assess the capability of the candidate to perform the job well. Why would you want to test irrelevant skills? Solving leetcode-style problems demonstrates a very specific skill: the ability to solve leetcode-style questions! Theoretically, these questions can be solved by applying many different strategies, but usually the accepted answer is the one that has the best time-efficiency: the problem statement is designed to force a specific solution over all others.

Let's look at some of the common patterns used in leetcoding: 2 heaps, memoization, fast and slow pointers, sliding windows, and similar algorithmic delicacies. These techniques are very rarely used in most software engineer jobs, and if someone tried to introduce them in their project it would probably be a case of premature optimization mixed with symptoms of the NIH malaise (aka Not Invented Here). For example, reducing the number of service calls in the system or improving a single SQL query will provide a performance boost several orders of magnitudes higher than the one achieved by obsessing over a masterful implementation of a dynamic programming hack.

This is not to say that leetcode-type questions should be avoided tout-court by developers. In fact, they are a fun exercise and, when approached with moderation, they can stimulate a broader view of software issues and stem lateral thinking. But I wouldn't expect anything else of substance, especially after factoring in all the hours of mindless grinding required to become proficient at these problems.

2) Leetcoding is a commoditized skill

Leetcode was invented to easily screen applicants in a standardized way. Unfortunately, it also brought the side-effect of standardizing the applicants themselves. The problem is that this type of question has been glorified as the surefire way to get into coveted Big Tech companies (and into Big Tech wannabes), increasing the number of people that devote themselves to this self-serving exercise and strive to become good at it. In turn, companies need to progressively raise the bar, stimulating a whole underwood of preparatory classes and books that teach how to "solve" interview questions in a standardized way.

The dark side of this kind of preparation is that a good understanding of algorithms and data structures that are commonly used in leetcode it's the bare minimum requirement: passing these questions requires hyper-specialized training over the span of several months or even years. It would be naive to think that the best engineers will naturally figure out the solution to the interview question: candidates train themselves to classify problem statements, recognize recurring patterns, and apply the required cookie-cutter solution in order to pass. In this way, it's impossible to really assess the unique abilities that make an applicant stand out.

3) It conceals the real value that an engineer brings to the table

Developing algorithms is sometimes the easiest part of a software engineering job. In Christina Lee's correctness pyramid, the foundational layer of building software is a set of detailed and clear specifications (I wrote about it in a previous article).

Maximum time leverage is achieved by understanding the right thing to do, properly communicating it with others, neutralizing foreseeable issues, and finding appropriate tradeoffs. It also helps to have a clear vision of the company goals, understand industry and internal best practices, and be able to summarize decisions with concise documents. The specific expertise and hard skills possessed by an applicant are crucial in predicting their ability to do the job.

I believe that there are many, brilliant, engineers more than capable to thrive in complex projects. Sometimes, they are also proficient at coding challenges. But how are they going to prove their overall worth like this?

4) Grinding leedcode problems hampers professional growth

As mentioned earlier, taming coding challenges demands a significant time investment. For any software engineer, the cost opportunity of doing so is huge. Let's imagine befriending Annie, a fictitious but very ambitious software engineer in her early 30s. She is very skilled at her job, but she desires to grow even more to achieve all of her career goals. After spending time with her loved ones, relaxing by playing the guitar, and doing long walks with her dog, she is still able to reserve an hour daily for self-improvement.

What should Annie do? On one hand, she could go full-on into leetcode mode, hacking their way into problems of growing difficulty: this will improve her chances to pass a leetcode question during a job interview. On the other hand, she could work on a side project to explore some shiny new tech. Maybe, after a couple of weeks, she will be able to show her creation at work and pique the interest of her colleagues. Her project later becomes the basis for an internal PoC that considerably shortens the time-to-market of a new company initiative. Everybody wins.

As an employer, what would you like Annie to do?

5) It encourages a conformist mindset

Go to a nice school, master leetcode, join a prestigious company, then change jobs every 2 years to increase your salary and collect brands on the resume. This is the perfect recipe for the modern software engineer. IT careers are being gamified: salary is the high score, interviews are midgame boss battles, and leetcode is the main way to gain experience points. Once the way is so perfectly laid out for us, it's difficult to even look elsewhere.

Conformity is great for producing widgets, but knowledge workers should be held to a higher standard, especially if they are required to figure out hard and ambiguous problems in their organization.

Conclusion

These are the 5 reasons I think we should forego leetcode-style questions in interviews. Do you agree with me? Or is leetcode a necessary evil?