leetcode and reasoning

Posted: June 24th, 2025 8:41 AM

There has been a lot of debate and discussion about the utility of a filtering system like leetcode for almost any software related position in the industry today. With the rise of tools like Cluely and others it does beg the question of if there needs to be a fundamental change in the way software engineering interviews are carried out. Maybe.

The most clear argument I can think of as to why one should not argue against leetcode like interviews is for the simple reason that there is almost no other way to adequately gauge a persons ability to reason through complex problems, carry out the solution, and then articulate each step to another human in real time. There is of course room for debate here, but thinking about the other implications makes it difficult to find real basis in any rebuttal. For example, if I am a self taught programmer who may not have the credential from the establishment to which you think I should have, that does not make me incompetent or incapable. For this scenario something like leetcode should be preferred.

This also means that a company could measure one's ability to come up to speed on a codebase and get into a decent marathon pace working cadence. They may not have X number years of production grade work in your MERN stack, but the fact that they can reason, comprehend, and articulate how to use a bloom filter shows a level of IQ and hopefully a measure of EQ that would suggest they could probably do as good if not better at X role on the tech stack as anyone else.

So there is a real value in grading the aptitude and ability of someone to perform this kind of reasoning. A common counter argument here is that one would simply memorize ~100 leetcode problems and then by chance get the question that they spent the most time memorizing and the entire value of the interview is thrown out the window. However, I'm not sure this has a high enough true occurence to really matter. Let's say for example that it is some ridiculous number like 20% of all software engineering interviews contain one of the 100+ memorized leetcode problems. The P() that they are asked a question which would require some level of reasoning ability is high enough that the interviewer then needs to be good enough to filter out the true phony candidates.

I'm also not entirely convinced that a candidate who can memorize the setup, execution, articulation, and potential additional scenarios or applications of an inverted binary tree is more useless than one who exercises raw brain power to solve the interview question. There is some intellect required of one who can put in even just the time to memorize, let alone the ability to do so well. If this kind of candidate is applying for a role which they may likely be unqualified for, I think there are enough additional factors to lower the overall weighted score of their leetcode performance against their entire candidate profile.

The second most clear argument I could think of as to why leetcode interview questions are a good candidate selection filter is because intellectual reasoning is only going to become more important with the deployment of more novel AI. Today, anyone can create a 'Cursor for ....' or some other random b2b scaled vertical SaaS business with $100k+ in MRR. So a project portfolio would then need to assume an even more rigorous interview process which would require the candidate to articulate the infrastructure of the project, the algorithms employed by the project, or the execution of the code in the project among any other list of things. At this point you not only need to have a project worth sharing and speaking about (hopefully one that relates incredibly well to the stack you will be working on) but you need a Master's level thesis disecting the project top to bottom.

The raw amount of time input into building and articulating a project of that scale seems fairly unreasonable for the average software engineer. Perhaps with the augmentation of AI in actually creating the project, this leaves enough cognitive workload on the person that they would naturally have to spend more time reasoning through the process as a whole and employ critical thinking. This is very likely and could be signal for how interviews can incorporate something reminiscent of leetcode level reasoning and articulation.

In no other scenario would someone be studying the theory, application, and internals of data structures and algorithms. I have never heard of anyone using a bloom filter other than a random hackernews post from months ago. I don't think many are using doubly linked lists often in their b2b enterprise SaaS SWE roles. So, is it true that anyone is really even reasoning through complex problems as we would imagine a Math professor would be doing each day? Are problems that are deeply complex and difficult to solve really being thought over, executed, and explained in as much detail or as intensely as something like a leetcode interview? I'm not convinced of it.

When I think of novel software that seems to have taken some complex problem and distilled a simple solution, I think of open source, single neet engineer built projects. They always come first in my mind. The second would be those working on the bleeding edge of technology innovation in the world today. This means AI interpretability, internals, and perhaps performance. I could imagine that there are troves of teams standing in front of the proverbial whiteboard using immense cognitive power to try and derive some solution or next step in the broader scheme of how the CNN is really working. If this is the case, then what is the rest of the world's software engineers really doing with their time?

Most businesses do not have awkward nuanced implementations of unique software that produces an exceptional value. Most companies are some basic implementation of a rendition of a CRUD app. The complexity comes from trying to modularize, microservice, encapsulate, and clean code the infrastructure into a X-number of concurrent users available and reliable software. In most cases this is essentially useless since there are very few applications in the world that have enough concurrent users to justify a truly nanosecond level response time and entirely distributed software platform that implements parallelization and concurrency at the highest possible level. For all of those engineers who managed to land a role at companies like these, I would sympathize that leetcode was a waste of time. Similarly, I would argue that they are also not the target audience for a real leetcode style interview.

Certainly I'm a hypocrite for writing about this as I have only just started really learning and studying leetcode. Something like two-sum seems like a simple enough implementation that could have some real world application that I'm blissfully unaware of at the moment. However, the true beenfit I have felt from studying two-sum, valid anagram, and valid palindrome are the reasoning through the problem and recreating a somewhat rudimentary implementation of some existing class method to count() the number of instances of X letter or number. The ability to get a problem that is a verbose and slighlty more complicated math problem of a 4th grade text book and then articulate in human language the actual solution to the problem drives hormones in a way that almost nothing else can. There is more than just the satisfaction of being able to implement the solution in X number of lines of code. The journey getting there is euphoric. Feeling the neurons firing at rapid pace as I puzzle together the algorithms to solve the problem is what software engineering should be like. It should feel like invention.

It could very well be possible to get some similar caliber of feeling and detail out of an interview that reviews a personal project. However, as I've said, this means an absurd amount of time that most people will spend working on a project that they are not truly passionate about. So, leetcode acts as a kind of insurance and UBI. Everyone can participate and get a somewhat equal shot at landing the role. Conversely, if you are oddly anti-leetcode you likely shouldn't be applying to some company to work on a problem you think is interesting. You should rather spend a few more weeks or months thinking about the things you are deeply passionate about and then begin your own work on that. This skill is something that needs to be cultivated and requires a completely different outlook on life, but will benefit you much more than memorizing some leetcode and landing a role at big tech. Again, for these folks who likely complain about leetcode (and should), you are not the target audience.

As we measure models today in their ability to reason or how they go about their trains of thought, we too will be selected based off of our own reasoning capabilities. Combine that with taste and some EQ and you are on your way to landing a job that pays well and should keep you mentally engaged. The raw compute of the brain is going to become more valuable as time goes on. Metal-made things will continually progress towards becoming commodities. It's inevitable.

lesson

learn to reason, execute, articulate, and present. the entire process of acquiring information, actioning it, and then discussing what happened is an invaluable skillset. this kind of performance and aptitude ought to be the main target of leetcode. spending time memorizing X-number of problems misses the opportunity to learn how to apply human reasoning with and throughout the problem.

study the theory and implementation of data structures and algorithms at a level so high that you could almost universally apply the knowledge.