LeetCode is an online coding site designed to challenge its users with algorithmic programming tasks commonly associated with the interviewing process for developers. I’ve been using LeetCode for years. While I wouldn’t call myself an expert at interview-style coding problems, I’ve still found real value in working through them—sometimes in unexpected ways. The problem is that few people use this resource and even fewer do it when not actively looking for work, despite the benefits. In this post, I’ll explore what makes these kinds of questions worthwhile and why studying them can sharpen your skills. I’ve assembled what I think are the most compelling reasons to push forward with these problems and some strategies to make it easier. But I’ll also take a critical look at the other side: the frustrations people have with algorithm-heavy interviews and the prep industry that’s grown around them.
Why These Questions Exist
Back in the early 2010s, I was preparing for coding interviews for the first time in quite a while. I had the obligatory copy of Cracking the Coding Interview – now in its 6th edition– and LeetCode would launch for another few years. At the time, some companies were known for asking those quirky brainteaser questions, like the one about how to time 45 minutes using two hour long “inconsistently burning” fuses. In retrospect, these riddles now seem indefensible as interview fodder, but it was one of those cool tech-culture factors developer interviewees had to grapple with at the time. I suspect that for some candidates, the silliness of those puzzles cast a shadow over algorithm and whiteboard problems, too—the very kind LeetCode focuses on. But coding questions have been around for so long, they almost feel like a foundational part of the process. I’m not even going to try to find the first citation.
There’s a whole cottage industry based on questioning simple, firmly entrenched social systems one has no personal power to actually change. Bear with me as I give an example: I was watching YouTube and The Algorithm™ served me a video on “How The Barter Myth Harms Us.” This video covers how some of the most well established thinkers on modern economics have come to understand monetary systems as a strict upgrade from or natural consequence of what the content creator argues is a mostly-imagined predecessor system known as barter. The YouTuber explains that systems of barter are typical in three situations:
- Where you have parties that will never see one another again,
- With people who are accustomed to using money but do not have any, or
- When the parties know exactly what they want from one another so barter is just a clear means of optimization for both parties.
Barter is too complicated to be a good system for daily commerce, the YouTuber continues, using the voice of those he criticizes. In contrast, money presents its users with a pretty simple series of steps: 1. Create value, 2. Turn that value into money through exchange, and 3. Convert the money via subsequent exchanges into the things you need or want. The pseudo-algorithm of money seems simple and universal; it describes simply the basic rules of interacting with other people economically. The video points out, however, that money and its assumed predecessor barter are not the only solutions and that money adds an impersonal aspect to these interactions that is not positive. Furthermore the idea of bartering, so this creator argues, is basically a straw man used to contrast with a monetary system rather than presenting an actual arrangement between real people for day-to-day economic interactions. This false alternative then serves as a means to justify the negative aspects of the monetary approach. My takeaway from the video is that many people, like this YouTuber, yearn for personal treatment from systems of rules that were not designed to yield such things. There is some analogue here to hiring practices I think.
This idea of breaking down human decision making into one homogeneous entity by using some universal solvent strategy is hardly unique to money. US News College rankings and College Board SATs serve similar purposes: to sort people and institutions for one another on a descending scale, allow those people and organizations to find their place in it and then accept the level of benefits accrued by that place. Likewise, on YouTube, The Algorithm™ sorts people by factors vague and otherwise to optimize watch time. People generally dislike being sorted, unless they are the beneficiaries. Sorting usually precedes or facilitates rejection, which feels impersonal because often it very much is. From the perspective of the recipient of rejection, the personal efforts put in are not matched by the efforts of the entity doing the rejection. This asymmetry seems unfair. Of course, those that are selected feel personally validated and rarely consider it further. Much like with the algorithm of money, the algorithm of prestige serves to alienate and to shift burdens from evaluators to applicants.
LeetCode: the Big Timesink
This brings me to the curious invention of LeetCode. The name, even if in an indirect way, includes an equivalent of the actual English word “elite.” The algorithm of prestige looms even in the name. I say LeetCode is curious because if you look at it for 5 minutes you will see that it is a website dedicated to what might look like some of the most monstrous math word problems you have seen, depending on your experience of course. What motivates people to engage with such things and why would it be as popular as it actually is? LeetCode is explicitly designed for developer job applicants who want to get an edge in the hiring process. For a long time, it has been well worth the investment too. There are forums with posts daily from people relating their hiring experiences with one another, sharing preparation strategies, providing solutions to specific algorithm problems, etc. One could argue LeetCode is a smaller scale social networking site. So what’s wrong with that?
Some people enjoy solving these problems, but for many it is a never-ending grind. Regardless of which of these options you are, if you want to be any good, it is a serious investment of time. Good code can be hard to write, especially from a browser window, and it can be even harder to debug there. One early mistake is to start solving a problem based on a misunderstanding of the task, which means any efforts up to the point of recognition of that misunderstanding are wasted. This experience is not without practical lessons, but it can be dispiriting nonetheless. Another common attitude about these problems is that you only truly learn if you solve the problem without help. That belief is a recipe for suffering and wasting time – there are explainers on most of the questions on the site and even just reading through them fully can be a chore. There are usually also resources not far from reach through a simple search, but then one must hone the ability to discern good resources from bad ones, which is in itself a matter of investing time together with trial and error. The point here though is that applicants invest time, then get sorted by employers, rather than employers investing time to find and develop potential. While these factors lie on a continuum, grinding LeetCode lives firmly on the applicant time-investment side and the relatively simpler sorting and rejecting side lies with employers. Stop Wasting Time on LeetCode, Try Code Reviews and Real-World Coding covers this complaint, saying “LeetCode was primarily intended for elimination rather than selection.”
Now having covered the fact that LeetCode is a huge time sink, I would argue that there are worse ways this industry could make hiring decisions than coding problems. At least this style of question is adjacent to a day to day type of task for a developer. I have taken some small part in the intake side of developer hiring and I find the objectivity of a coding puzzle a bit more useful than subjective notions like trying to identify specific personality traits or style, or murky subjects that will never be fully revealed or quantified in a simple hour’s interview like actual experience and specific personal contributions made. Asking for those is fine, it’s harder to engage in puffery when attempting to solve an actual coding problem. Working with code and a simple problem provides a pretty straightforward gradient on which to compare candidates almost anywhere on the spectrum of skill. The fact that one can put time into it and get better at it can be a grace, rather than a shortcoming, if the long term view is taken and there are some great ways to have fun along the way.
On the Bright Side
Gamification is one way that LeetCode and other platforms like it can mitigate the grind. It allows you to feel a sense of progress and provides motivation. There’s an acknowledgement for just having logged into the site each day and a daily problem that can drive variety. You can submit solutions and see if they get any interest from other users. I realized my solutions in Java and Python would be competing with a ton of others, so I learned some Racket (a Lisp dialect) and posted some for that language. The full test run of your solution also comes back with memory and time metrics which one might think of as a kind of score. These metrics are placed in percentiles and provide a sense of competition. Although there are times when the metrics seem to be less than perfectly useful, there are places here and there where you might question their validity, especially when the range is wide and the measurements clump together or when repeated runs yield very different results.
While gamification makes the site engaging and may even aid learning, it is misleading sometimes, especially if you’re avoiding things you prefer not to figure out. Using the site can get into a kind of slot machine pattern where you will tweak, resubmit, and tweak again, which is a pretty bad habit that may speak to a lack of intuition or specific direction on the solution. LeetCode has a kind of cheat-the-system feel sometimes; people claim to know which questions are active with certain employers and there are discussions on how to slide past certain types of problems the easiest way – there’s always “that one weird trick” kind of thought process.
There are of course competitors to LeetCode as a programming problems site. LeetCode feels a bit less structured an experience as compared to a site like HackerRank. There are thematic lists of problems on LeetCode, but HackerRank seemed to have more of a linear progression from problem to problem. It does not hurt that HackerRank also allows code completion to be a non-paid feature and that getting used to how HackerRank works will actually help you with some of the interview processes that actually use their systems, but not necessarily their questions. Often while googling specific things doing a leetcode you’ll run into GeeksForGeeks, which provides interesting guides on these subjects. GeeksForGeeks is ad supported, which often adds a distraction factor that is quite difficult to deal with when trying to learn. Miraculously LeetCode has only some small ads in limited places, but I hesitate even to give them ideas. There are other more math oriented sites like Project Euler, which provides problems whose solutions will help users in later problems. Since at its core LeetCode and sites like it are really just lists of problems and answers, open source projects exist to fill the same gap.
One of the ways of learning from LeetCode I found most valuable was actually working on problems with other people in real time. I’ve worked with three different people on problems like this. Just getting better at verbally expressing ideas relevant to the problems and active listening makes collaboration a good idea. Having other people around also increased the incentives to timebox the effort and have some sense of achievement from the limited time mutually available. It also provided a lot of opportunities to see problems from different angles and learn a few new tricks. Often deciding when to call it quits on a debug session and to go read up on the article was difficult but was necessary just to try and get some discernible takeaway from the session.
There are some rather practical benefits to using LeetCode. I think doing LeetCode was a pretty great way to get more comfortable with Python, which I use frequently at work as a secondary language. The differences in usefulness and choices in language design between Python and Java became clearer to me as I sought similar tools for problems between the two. I learned about certain techniques and data structures I actually had not heard of before I used LeetCode – dynamic programming for example is fascinating to me. I’ve learned to appreciate some data structures more, for example I did not know anything about disjoint sets before I struggled with the well known island genre of problems, but the data structure seems to be one of those potentially useful ones that flies under the radar when going through the basics at school.
Ideally, LeetCode is a way to sharpen skills acquired elsewhere, acting as a study guide or supplemental resource, but I found myself actually reaching further in and dedicating more and more time. That is where most of the improvement for me came from, but while authors attempt frequently to take on a formal tone, it is often hard to estimate how seriously to take the words of likely some recent CS grad doing an hourly contract gig or at worst some random internet denizen whose experiences may mostly come from leetcode itself. When I realized a lot of the explanations on the site were based on material that could probably be better digested in a more comprehensive form, I started looking for books. This led me to Donald Knuth’s The Art of Computer Programming, which I put some into.
Knuth’s book reminded me of my days in undergraduate studies in my many math classes. It reignited a real interest in math for me and so I got the prerequisite book Concrete Mathematics. Both of these books are written in a witty and charming style, but they are also both humbling in their scope and complexity – there is so much material here, well beyond the trivia needed for a job interview. Even though I often fail to fully understand Knuth et al., I find it much more useful than the treatments on LeetCode. I learned Knuth’s fictitious assembly language “MIX” and found an actual running virtual machine for it in a Debian project. I learned to use some LaTeX to make my math homework pretty, related to another Knuth invention.
Finally, it’s a bit scary that LLM’s do have some success with LeetCode style problems. There have been many claims made about the proficiency of modern AI on coding challenges, Testing LLMs on Solving Leetcode Problems | HackerNoon https://hackernoon.com/testing-llms-on-solving-leetcode-problems has been an interesting example. The article describes an experiment performed on ChatGPT using coding questions. The author has worked on demonstrating ChatGPT’s capabilities in doing interview style programming problems. Speaking of the general format of LeetCode, the author says “These rules were not invented by Leetcode; they have been commonly used in computer science contests for quite a long time.” The author sought problems that the model hasn’t simply seen the solutions to already (i.e. were already in the training data) but calls the ones he provided for testing “unseen”. He concludes that, “all LLMs share a similar performance pattern: they produced decent results on ‘well known’ problems but struggled with ‘unseen’.” I think it makes sense that LLMs should be good at problems with rote explanations, which might be glossed over by detractors or people without enough time to invest. But then it has always been about time, really.
Beyond the Grind
Ultimately, my relationship with LeetCode—and the broader culture of algorithmic interviews—has been one of reluctant respect. For all its flaws, it provides a structured way to improve a real skill, and like any tool, it’s what you make of it. What’s clear, though, is that hiring practices are deeply entangled with broader systems of sorting, evaluation, and prestige. LeetCode didn’t create this structure—it just fits neatly within it. Whether you’re grinding problems for a job or exploring deeper computer science through Knuth, it’s worth asking what you’re really trying to get out of it: a job, a skill, a sense of mastery? There’s no shame in using the system, but we should remain conscious of its values—and our own.
