For a long time I treated this subject as a kind of social test in our field: something a bit caricatural, a bit exaggerated, almost as if it were more marketing than engineering. I looked at the obsession with algorithms and thought a lot of people were overestimating it, especially compared to what I always considered genuinely more useful: building systems, understanding context, designing solutions, making decisions responsibly.
But over time, I started noticing that a lot of our confidence comes from the context around the problem. When there is already a framework, a pattern, a stack and a more or less expected path, we gain speed almost without noticing. The difference shows up when that context disappears and only the problem is left: bare, with no ready-made track and nothing to lean on.
And then it started becoming clear to me that delivering a feature inside a known context is one thing, and sitting in front of a problem that comes with no script at all, having to genuinely think before writing a single line, is another.
I have criticised LeetCode before because I always thought system design was a more honest measure of maturity. And I also spent a long time watching people, often above me, treat trees, graphs, traversal or optimisation as if it were overengineering, when in fact the problem was being read at the wrong layer. What was missing was not just solving it, but understanding the theoretical origin of the solution and the right way to approach it from the start.
That is when I started realising, in practice, that technical interviews do not forgive improvisation. And I say that with the experience of having interviewed other people technically, not only from having sat on this side of the table. For more senior, specialist or technical management positions, the conversation escalates quickly: it does not help much to be confident talking about architecture, product or stack if, when the problem comes, the reasoning does not hold. When the exercise leaves the trivial, there is little room left for a nice speech.
the reality of the technical interview
This became even clearer after some very concrete experiences. There was a process at Amazon where I spent more than two hours staring at a problem I did not even know existed, and a process at Uber where I came very close to finishing the challenges, but not close enough within the time I had. And I do not bring this up as a defeat, but as evidence that there is a kind of reasoning that only appears when the problem forces you to read beyond the surface. Sometimes I even solved part of it, sometimes I got close, but that was never the point. The point was realising that I did not yet command, with the same ease, the kind of thinking the platform was asking for.
For a good part of my career I saw a lot of people, including me at times, set algorithms and theory aside, because market pressure always pushes everyone toward what is more sellable, faster and more immediately useful. When you spend too long only on what delivers immediate results, you start lacking the repertoire to calmly read problems that demand more than repetition. That is why books like Cormen remain fundamental, even if many people never work up the courage to touch them. And it is also why there are friendlier entry points, like Grokking Algorithms, which help you start without so much intimidation, even though they do not replace the depth of the more classic texts.
In the end, I came to understand that LeetCode is not a judgement of worth, but a very specific training in reasoning. It forces you to think about patterns, cost, memory, data structures, strategy and, above all, how to justify a choice. If I cannot explain why a solution works, I have not fully understood what I did.
That is why I decided to turn this into a series. I want to document my journey with more direction and, at the same time, help other people on the same path. The idea is to record the whole process and share what I learn in blog posts, videos and in the algorithm-solutions repository itself.
the market is a mess
So yes, I am going to own this rant. If the alternative is staying stuck in a sequence of ATS systems, automated screening and increasingly opaque filters, then maybe it makes more sense for me to prepare for a process where my capabilities show up more directly. In the end, I would rather depend on what I can actually think through and solve than be at the mercy of some AI's judgement.
being a nerd is part of the game
There is another side to all of this that I like to admit without shame: I like being a nerd. I like that feeling of taking something that looks simple and going deep enough to show there is more there than the first reading gives you. That is what improves the quality of the solution and the depth with which I see problems.
If I am going to talk about LeetCode, I want to do it properly. The way I would have liked to read it when I was still getting beaten up by these problems. If you are on this path too, stick around; I am going to document the process.