Why I Stopped Optimising For Points

I spent two years grinding LeetCode. Medium and hard, mostly, sometimes contest ratings. It felt productive in the way that only things with a number attached can feel productive.

Then I started a real project and realised almost none of it transferred.

What grinding actually gave me

Genuinely useful things, to be fair:

• Recursion stops being scary. After a few hundred tree and graph problems the call stack is just a thing you manage.
• I can pick a data structure. Not perfectly, but quickly, and I know what the trade-offs cost.
• I can read an unfamiliar algorithm and follow it. This is underrated and it comes straight from solving things written in the most compressed style possible.
• Interviews stopped being a different skill. I know what they are testing. That removes a whole layer of nerves.

That is a real list. I am not going to pretend the two years were wasted.

What it did not give me

Almost none of the actual work.

Nobody has ever asked me to reverse a linked list in constant space. They have asked me to design a schema that survives three years of growth, to make a slow page fast, to work out why a race condition only appears under load, and to explain a decision to someone who will have to maintain it.

None of those are LeetCode problems. All of them are the job.

The specific failure mode I hit: I could solve "design a rate limiter" as an interview exercise, and I could not build one, because the interview version has no configuration, no persistence, no failure mode, and no user. It was a toy wearing a real problem's clothes.

The pattern-matching trap

The deeper problem is that grinding trains a specific and narrow skill: recognising a problem you have seen before. That is genuinely useful for interviews and almost useless for work, where the interesting problems are the ones you have not seen.

It also quietly reorders your priorities. Pattern recognition is measurable, so it becomes the thing you measure. Reading a book is not measurable. Understanding an architecture is not measurable. So I did the measurable thing, and the unmeasurable thing atrophied.

What I do now

I still solve problems. Maybe two a week, and never on a streak. But I stopped counting, and I started reading actual code instead, which is much slower and has taught me considerably more.

The other change matters more. I try to spend roughly a third of my learning time on building something that exists to be built badly, and a third on reading how people solved a problem properly, and only then on exercises.

It is a much worse ratio for my streak and a much better one for my work. I would like to think I would have made this trade at the start. I am fairly sure I would not have.