I’ve been solving algorithm problems lately, and I keep noticing the same thing.
In almost every problem, there is a small, clever move that turns the obvious solution into the good one. It’s rarely the algorithm itself — the algorithm is usually a well-known pattern you can name. It’s something smaller. A choice to overwrite instead of delete. To track one number instead of a list. To update state instead of recomputing it.
The named patterns are the easy part. You can read about two pointers, binary search, dynamic programming, and then you know them. But knowing them doesn’t solve the problem. What solves the problem is noticing the specific reframing that makes the pattern apply, and that reframing almost never has a name.
The named and the unnamed
Some of these moves do get named eventually. Incremental computation is one — the idea of maintaining state as you move forward instead of recomputing it from scratch. Once you see it, you start spotting it everywhere: sliding window sums, Kadane’s algorithm, prefix sums, in-place overwriting. It’s a real principle and it’s worth knowing.
But for every named move there are ten unnamed ones. The trick that only works because the array is sorted. The observation that you don’t actually need to store all the values, only the maximum so far. The decision to iterate from the right instead of the left. These don’t go in textbooks. They live in the gap between problems.
Where the magic lives
For a long time I thought the people who were good at this were just smarter. They saw the trick and I didn’t, and that was that.
I’m starting to think it’s something else. It’s not that they’re inventing the moves on the spot — it’s that they’ve seen so many problems that the new one rhymes with something they've seen before. The 501st problem feels familiar because it shares a shape with the 47th. The move isn’t genius, it’s recognition — just like in chess, where grandmasters don’t calculate further than amateurs, they just see the position.
Which means the gap between knowing the algorithm and seeing the move is closed by volume, not by talent. You solve enough problems and the patterns start to leak across them. You stop seeing “a sliding window problem” and start seeing “a problem where the answer only depends on a small local update.”
I don’t think you can train this directly. You can’t read your way into it. But you can practice asking the right question every time you finish a problem: what was the small move here, and where else might it apply?
A wider claim
I think this generalizes beyond algorithms.
The same instinct — the one that picks the right data structure, the one that notices you don’t need to recompute the sum — is the one that picks good abstractions, good API shapes, good variable names, good ways to break down a task. It’s taste. And taste, as far as I can tell, is just pattern recognition that’s been running long enough to feel like intuition.
The magic is real. It’s just made of practice.
NOTE
Continued in The residue is the point, which asks whether this kind of practice is still worth it in the AI era.