Leetcode is one of those polarizing topics that you either love or hate. But what exactly is it? And does it even deserve your attention?
The "grind" bit aside, Leetcode is just a platform where you can solve programming puzzles of varying difficulty that cover a wide range of data structures and algorithms (DSA) topics, like trees, dynamic programming, linked lists, string manipulation, and much more. Many of these problems require that you find an optimal solution, in terms of time or space complexity (or both).
Used generally, the term "Leetcode" (or, in its verb form, to Leetcode) doesn't necessarily refer to that particular platform. Rather, it refers to a range of platforms—including Hackerrank, Geeksforgeeks, CodeChef, and more—that are meant to help you practice solving technical interview problems and coding puzzles.
In principle, Leetcode seems pretty harmless, right?
Unfortunately, most of the tech industry has adopted Leetcode as its unofficial method of standardized testing: a way to weed out those who can't solve an unfamiliar problem on a whiteboard, without Googling and without enlisting help from their co-workers. Because, as we all know, these skills are irrelevant in the workplace.
Due to how frequently these types of questions are asked during technical interviews, certain online circles—especially subreddits like r/cscareerquestions—have come to develop an almost religious obsession with the so-called "Leetcode grind." It's way of life wherein you devote a majority of your time to cranking out Leetcode or Hackerrank problems in preparation for technical interviews at FAANGs: the Facebooks, Amazons, Apples, Netflixes, and Googles of the tech world.
And like any obsession, the Leetcode grind is nothing short of unhealthy.
You've never truly experienced Leetcode unless this sounds familiar:
- Decide that you're going to finally tackle Leetcode.
- Get stuck on an Easy problem.
- Give up 10 minutes in and look at the solution.
- Fail to understand said solution.
- Google "Leetcode sucks" and read some encouraging rants on Reddit.
- Revisit step 1 about a month later.
And yet, it's not exactly healthy when you think about it—not any healthier than the actual "grind" mentality itself. Rage-quitting Leetcode is just about as bad as not trying in the first place.
I used to despise Leetcode. Unfamiliar problems would frustrate me. Obscure solutions and math tricks would practically get my blood boiling. Who cares about any of this? When will any of this be relevant?
Sound familiar? It's like complaining about learning bio or physics in an undergrad program, when you'd much rather focus on your chosen specialization (which, in my case, was computer science). Yet the point of most academic programs is not to just teach you how to become a software developer, physician, or whatever your heart desires—it's to ensure that you get a well-rounded education that exposes you to a number of disciplines and problems.
Leetcode, like most things academic, is healthy in moderation. There's absolutely nothing bad about practicing your problem-solving and optimization skills, or learning new ways to approach an unfamiliar problem in software development. What is unhealthy is the so-called "Leetcode grind." It's unnecessary—and, frankly, just one piece of the overall puzzle.
Want to ace your interviews? Good luck doing that if you've tunnel-visioned into the Leetcode grind. What about these other important skills?
- Polishing your resume.
- Practicing answers to soft questions.
- Preparing questions for interviewers.
- Researching companies.
- Writing compelling cover letters.
- Working on side projects.
Where do these fit into your day when all you do is crank out Leetcode problems?
Perhaps the most glaring issue with the "Leetcode grind" mentality is the fact that it only helps if you actually make it to the technical interview. If you don't, what use is it to you? You're much better off figuring out why you're not making it to the technical interview in the first place.
In my case, the issue was a poorly developed resume. I highly encourage you to share yours with others and to get feedback so you can present your best self to employers.
Fortunately, not all companies use these types of problems to weed out applicants. In fact, in all of the interviews that I've done to date, I'd say that I've maybe had to do only one or two Leetcode-esque problems. The rest have been practical interviews:
- Low-pressure pair programming on platforms like Coderpad, where Googling is allowed.
- Bug fixing and simple skill tests, with practical problems relevant to the job you applied for.
- Take-home assignments or codepen challenges.
- Walking through hypothetical scenarios out loud, like how you would design a REST API.
- Quizzing me on my computer science and programming fundamentals knowledge.
- Asking questions related to the tech that I'd be using on the job.
Part of the blame for the Leetcode grind mentality falls on the tech industry—there are so many creative ways you can test a candidate's competency, especially as it relates to the job they'll be doing. Interviewers should put in just as much work to develop an interesting and challenging exercise (or set of exercises) to test your abilities, if they expect you as the interviewee to show any interest. But why bother to put in that effort when you can just Google a generic problem, slap it on a white board, and pretend to seem interested in the interviewee's solution?
In some ways, Leetcode is practical. For one, it teaches you to always solve a problem using a brute-force approach and to only worry about optimization once it's needed. Usually, it's fairly easy to come up with a brute-force solution to Easy or Medium problems, even if it's not perfect.
In the real world, unless your solutions are always on the order of
O(N3) (or, god forbid,
O(2N)), a brute-force solution will be more than good enough. In fact, brute-force solutions are usually pretty easy to understand because they involve some sort of stepwise iteration or problem simulation. Good examples of these kinds of problems are ZigZag Conversion and Merge k Sorted Lists. All it takes is for you to work through solving the problems by hand, and the insight comes naturally with practice.
Then just stop—that's all there is to it. Leetcode is only a grind if you let it become one.
Lately, I've made it a habit to practice one or two Leetcode problems a day, for the sake of preparing myself to solve these kinds of problems more proficiently over the long term. If one day I don't feel like practicing Leetcode, then I simply don't.
Leetcode, like all skills, takes practice and time to perfect. If you expect to solve Medium and Hard problems within minutes of reading them, you'll be disappointed and walk away frustrated. You'll beat yourself up. You'll think you're stupid and not cut out for dev.
Treat Leetcode as a fun exercise to keep yourself sharp. Don't treat it like a school assignment or an interview. Practice solving these problems casually, without Googling, and you'll eventually pick up on patterns.
Rather, work through the problems in order, or at random. This may seem counter-intuitive, but it makes a world of difference. Certain types of problems, like string manipulation, are immediately recognizable regardless of whether you've narrowed down the list of problems by topic. But others require you to have developed an intuition for recognizing the type of problem that you're given. Just two examples are DP problems and sliding windows. If you approach one of these problems knowing what you're looking for, then you're cheating yourself out of part of the challenge and making it easier. This doesn't model a real interview, where you won't be told what type of problem you're working with. That's up to you to figure out!
You should at least work on a brute force solution. If you're truly stuck, start reading the solution, but don't just jump to the code. Try to understand the reasoning. If at some point a lightbulb goes off in your head, try to revisit the problem and work through it yourself before spoiling the solution.
Yes, Leetcode rewards points for solutions. Yes, elitists love to brag in the discussion section about how their solution is faster than
X% of Language submissions. These metrics are almost meaningless, and you'll get different numbers each time you submit a solution. This is missing the point of Leetcode entirely. Don't obsess over performance metrics. If your solution is optimal and passes, that's all that truly matters.
This one is sort of optional, but I find that it's a great way to kill two birds with one stone: practicing Leetcode and ensuring that you stay on top of your chosen language's fundamentals and syntax. It's a good way to keep things fresh in your mind.
The greatest athletes, chess players, and actors of the world didn't achieve their prestige without practice. You can't expect to ace technical interviews immediately.
My submissions fail pretty frequently, with only a 40% acceptance rate for the 60 problems that I've solved to date. And I'm okay with that, as long as the number doesn't continue to drop over time.
So forget the grind—just focus on the value of practicing Leetcode, not on doing as many problems as you can in one sitting.
This post's social media preview image uses the Leetcode logo under fair use; it is under the copyright of LeetCode. I am not affiliated with LeetCode.