I Solved 100 LeetCode Problems Before I Realized I Was Studying the Wrong Thing

At problem 47 I thought I was making progress. At problem 83 I was confident. At problem 100 I felt ready.

Then I failed the interview. Not because the problem was impossibly hard. Because I had solved something similar dozens of times and still could not figure out the approach in the first five minutes. I knew the solution existed somewhere in my memory. I just could not reach it under pressure with someone watching.

That experience forced me to think honestly about what I had actually been practicing for three months. The answer was uncomfortable: I had been practicing executing solutions, not recognizing patterns. Those are two completely different skills. The interview tested the second one. I had built only the first.

What grinding 100 problems actually teaches you

When you solve a LeetCode problem and get it accepted, you learn several things. You learn the implementation details of the solution. You learn the time and space complexity. You practice translating an algorithm into working code. These are real skills.

What you do not learn is how you would have arrived at that solution if you had never seen the problem before. Because you have seen it. You read the title, recalled that it was a sliding window problem, and started implementing. The pattern recognition happened automatically because the problem was not new to you.

The issue is that in an interview, everything is new. You do not get to look at the title and remember your notes. You read a fresh problem statement and need to identify the structure from scratch, with no hints, under time pressure. That is a skill you can only build by practicing recognition on problems you genuinely have not seen.

Most people never practice this. They solve problems they have already categorized. They feel productive because they are writing code and getting correct outputs. But the moment they encounter an unfamiliar problem, the recognition process that usually happened automatically does not fire. They know all the patterns and cannot tell which one applies.

The recognition gap

Here is a specific example of what I mean. Sliding window and two pointers are both patterns that involve moving indices through an array. Most developers who have practiced both can implement either one when they know which to use. But ask them to distinguish between the two on an unseen problem, and many will hesitate.

The actual distinction is structural. Sliding window problems involve a contiguous range with a condition on the range itself. You are asking "what is the longest window where the condition holds?" Two pointer problems involve finding a pair or partition. You are asking "is there a pair that satisfies this condition?" The signals are different. The word "contiguous" or "subarray" points to sliding window. The words "pair", "sorted", or "two elements" point to two pointers.

If you have internalized that distinction, you can make the pattern decision in seconds. If you have not, you will sit staring at the problem trying to remember which one it was when you solved similar problems before.

The gap between "can implement the pattern" and "can recognize when to apply it" is the gap that costs people interviews. Almost everyone has closed the first gap. Almost nobody has deliberately closed the second.

Why more problems does not fix this

The intuitive response is to solve more problems until the recognition becomes automatic. This does work, eventually. But it requires an enormous number of problems and has a high ceiling on how well it transfers to genuinely novel problems.

The reason is that learning through problem volume is learning through exposure, not understanding. You learn "this type of problem" rather than "this structural signal in a problem." The first is a lookup table. The second is a framework that generalizes.

A lookup table works until it does not. When you encounter a problem with the same underlying structure but described differently (the same sliding window logic framed in terms of a temperature reading instead of a subarray), the lookup fails. The structural recognition still works.

Building structural recognition intentionally is faster and more transferable than building a lookup table through volume.

The practice shift that changed how I approached this

The shift was simple. Before writing any code on a new problem, I forced myself to answer one question: what structural property of this problem tells me which approach to use?

Not which algorithm. Not which data structure. The structural property. Is the problem asking for something about a contiguous range? Is it asking me to find a pair? Is it asking whether something is possible, and does the answer to the full problem depend on answers to smaller versions? Is there a graph and I need the minimum steps?

Each of those structural properties maps cleanly to a pattern. Contiguous range condition maps to sliding window. Find a pair in a sorted structure maps to two pointers. Minimum steps in a graph maps to BFS. Answer depends on smaller versions of the same problem maps to DP.

Once I started practicing the structural diagnosis before implementation, two things happened. First, I got faster at pattern recognition because I was building a decision framework rather than a lookup table. Second, I got better at novel problems because the framework generalizes to problems I had never seen.

The same seven structural properties cover roughly 90% of the problems you will see in a coding interview. The patterns are not mysterious. The skill is diagnosing which one applies quickly and reliably under pressure.

What the interview actually tests

The framing that changed how I prepared was this: an interviewer who gives you a coding problem already knows you can look up the solution. They are watching something else.

They are watching how quickly you move from "I do not know this problem" to "I recognize the structure of this problem." They want to see you read a problem, identify that it has overlapping subproblems and optimal substructure, and say out loud "this looks like DP, let me define the state." Or read a graph problem with uniform edge weights and say "I need the shortest path, so BFS with a queue."

That transition from unfamiliar problem to recognized structure is the skill. It is built by practicing the diagnosis deliberately, not by accumulating solved problems.

The developers who perform best in interviews are not the ones who have solved the most problems. They are the ones who can take an unfamiliar problem, identify its structural signature in under two minutes, and start building the solution from that foundation.

The seven structural signatures

For completeness, here are the seven patterns and the structural property that signals each one:

Sliding Window: the problem asks for something about a contiguous subarray or substring of variable or fixed size.

Two Pointers: the problem involves finding a pair, triplet, or partition in a sorted array where comparing elements from opposite ends leads to the answer.

BFS: the problem asks for the shortest path or minimum steps in an unweighted graph or grid.

DFS and Backtracking: the problem asks for all combinations, all permutations, whether a path exists, or asks you to build a solution incrementally while undoing bad choices.

Binary Search: the problem involves a sorted structure, or asks for the minimum or maximum value that satisfies a condition you can verify in linear time.

Dynamic Programming: the problem asks for the maximum, minimum, count of ways, or whether something is possible, and the answer to the full problem depends on answers to smaller versions of the same problem.

Dijkstra: the problem asks for the shortest path in a weighted graph with non-negative edge weights.

Learning these as a list is useful. Practicing diagnosing them from problem statements is what makes them work in an interview.

If you want to see each pattern executing step by step, with live state, pointer positions, and your own code running through the same engine, Expora walks through all seven interactively: Coding Interview Patterns: The 7 That Cover 90% of Interviews

The reframe

The question is not "how many problems have I solved?" It is "can I read an unfamiliar problem and identify its structure in under two minutes?"

Those are different questions. The second one is harder to answer honestly and more directly related to interview performance.

One hundred problems solved without deliberate pattern recognition practice produces a developer who performs well on familiar problems and struggles on novel ones. Fifty problems with deliberate structural diagnosis practice produces a developer who can handle unfamiliar problems because they have built a framework, not a lookup table.

Build the framework. The problems are just the training data.