Metacognition vs pattern recognition

Most people believe the skill being tested is recognizing patterns. You see a problem, you work out which of the templates you know it matches, you apply that template. It is not the skill, and believing it is will quietly cap how far you can get. The actual skill is solving the problem, and pattern recognition is just one tool you sometimes reach for along the way. Get the order wrong, reach for the pattern first, and you have stopped thinking. You are matching shapes, and the moment a problem does not match a shape you have already memorized, you have nothing.

The whole "N patterns solve most of LeetCode" genre is built to train exactly this habit.

These posts always end on the same line: you are not bad at problem solving, you are just bad at identifying patterns. It is precisely backwards. Identifying patterns was never the skill. The reason the claim feels true is that any single platform does not contain much variety, so a few dozen templates really do cover a large fraction of its problems, right up until something genuinely unfamiliar shows up and you find there was never anything underneath the templates holding you up. It is a whole content category by now, every entry selling the same shortcut.

So let me show you the other way, because "reason from the constraints" is easy to say and useless until you have actually watched it happen. We will take one small problem, solve it the lazy way first, then the real way, and you will see that the answer comes out identical and the skill does not.

Reasoning your way to a trick

Here is the problem. You are given an array of n numbers, and every number is somewhere between 1 and n. Some of the values in that range appear, some do not, and you want to return all the values from 1 to n that are missing from the array.

The pattern-matching move is immediate. This is a "did I see each value" question, so it is a set problem: throw everything into a hash set, walk 1 to n, report whatever is not in the set. Thirty seconds, O(n) time, O(n) extra space. If that is all the problem asked for, there would be nothing here worth learning.

So let us add the one constraint that forces you to think: do it in O(1) extra space. No set, no second array.

Now the template is gone, and this is the exact moment that separates the two skills. The pattern matcher is stuck, because "find the missing ones with no extra memory" is not a shape they have a name for. The reasoner does something different. They stop hunting for a technique and start staring at what is actually in front of them. What is special about this particular problem? The values are in 1 to n. The indices are 0 to n minus 1. That is the same set of slots, shifted by one.

That single observation is the whole solution, and notice it is an observation about this problem, not a label imported from another one. If the values live in the same range as the indices, then the array can be its own set. You never needed a separate place to record "I have seen value v"; index v minus 1 is already sitting right there. You only need to flag it without spending memory, so flag it with a sign: when you encounter a value v, make the number at index v minus 1 negative. Everything started positive, so a negative entry means "something pointed here." One catch falls straight out of the reasoning, and you would hit it yourself the instant you started coding: the value you read might already have been negated by an earlier step, so you take its absolute value before using it as an index.

Make that one pass, then a second pass. Every index still holding a positive number was never pointed at, which means its value, the index plus one, never appeared. Those are your missing numbers. O(1) extra space, and you never reached for a data structure at all.

Here is the part that matters. The final idea, using the array itself as a hash table by marking signs, is a real, named, reusable trick. A pattern person might even have it on a list somewhere. But you did not get there by recognizing it. You got there by noticing one structural fact, that the values and the indices share a range, which was forced on you by one constraint, that you had no spare memory. The code a "patterns" person writes and the code you write are byte for byte identical. The skill that produced them is not, and only one of the two will still fire on the next problem, where the surface looks nothing like this one and there is no list to check.

Learn ideas, not just concepts

A distinction that helps here. A concept helps you understand a problem. An idea is something you can act with, and it generalizes. "Sums over intervals of an array" is a concept; "use a prefix sum" is an idea. "The best answer over a moving window" is a concept; "try a sliding window" is an idea. What you want to collect is ideas, each one paired with the reason it applies, because the reason is the part that carries to the next problem. A solved count collects nothing.

If you can clear mediums but freeze on anything genuinely new, this is almost always why, and the fix is not more patterns. It is to take problems you have truly never seen and make yourself reason a path out of the constraints before you reach for anything you happen to recognize, exactly the way we just did.

This talk is the clearest thing I know of on internalizing that rather than memorizing routes: