Coding Interview Readiness: Your Problem Count Is Not the Signal

You've solved 200 problems. Is that enough? How about 300? At some point during every prep cycle, engineers start doing this math in their heads, refreshing the LeetCode solved counter like it's a stock they own.

The counter is lying to you.

Not because volume doesn't matter. It does. But "number of problems solved" is a lagging indicator of real readiness: whether you can walk into an interview, read a problem you've never seen, and derive the right approach without recognition cues. That skill and your problem count are correlated but not the same thing. Conflating them is how you end up with 300 problems solved and still blanking on a medium at the actual interview, staring at a whiteboard like you've never touched a computer before in your life.

The Number Everyone Cites Is Barely Predictive

Interviewing.io analyzed nearly 700 users and measured how total problems completed correlated with interview performance. The correlation was 0.27. Positive. Real. But a 0.27 correlation explains roughly 7% of the variance in your outcome. That's barely better than the alignment of Venus with Mercury.

That something else is whether you've genuinely internalized the underlying patterns. Someone who solved 150 problems with real understanding typically outperforms someone who ground through 500 by copying solution approaches. Engineers using spaced review systems averaged 150 to 175 solved problems and outperformed those who ground 500+, because they retained what they learned.

The Ebbinghaus forgetting curve is brutal here. Without review, you lose roughly 70% of new information within 24 hours. Solve 500 problems over three months without revisiting them, and most of that work has evaporated by interview day. Your brain just quietly deleted it to make room for song lyrics and podcast opinions. Your problem count is how many things you've tried to learn. Your retained pattern count is how many tools you actually have when the interview starts. These are very different numbers, and almost everyone is confusing them.

There Are Roughly 15 Things You Actually Need to Know

Interviews are not infinite. The problem space is large but the pattern space is not. Research across hundreds of tagged interview problems at FAANG companies lands on about 15 core patterns covering roughly 90% of what gets asked:

Two pointers (converging for sorted arrays, fast/slow for linked lists)
Sliding window (fixed and variable size)
Binary search (on data and on the answer space)
Prefix sums
Hash maps and frequency counting
BFS and DFS (trees and graphs)
Backtracking
Dynamic programming (1D, 2D, interval DP)
Greedy
Heaps and top-K elements
Monotonic stacks and queues
Union-Find
Intervals
Topological sort
Tries

If you have genuine coverage on all 15, meaning you can reproduce each approach from scratch without prompting, you're qualified to attempt virtually any medium that shows up in a FAANG loop.

If four of these are missing, you're guaranteeing failures on roughly 25% of problems before you even read them. A candidate with 100 problems and genuine coverage on 12 of 15 patterns beats someone with 400 problems crammed into four categories. Every time. Even though the 400-problem person looks more prepared by every quantity metric.

Pirate confidently declaring that inverting a binary tree is trivial This is what genuine pattern fluency feels like. You want to be this pirate.

Gaps matter more than totals. That's the whole thing.

Volume Without Identification Practice Trains the Wrong Skill

Grinding produces one thing: you get good at executing solutions once you know what technique applies. The problem is that interviews test a prior skill. They test whether you can identify which technique applies in the first place.

Cognitive science distinguishes between "blocked" and "interleaved" practice. Blocked practice is solving 20 graph problems in a row, labeled as graph problems. You get good at graph execution. Interleaved practice is mixing problem types without labels, forcing your brain to identify the pattern before applying it.

Most people practice in blocked mode and get tested in interleaved mode. LeetCode's category filters make it easy to stay blocked forever. You grind the "Dynamic Programming" tag and feel productive. You're not being productive. You're doing tag-assisted problem solving, which is a different activity from the one the interview measures. In the actual interview there is no tag. You read a description and have to decide: is this DP? Is it greedy? Is this a graph problem in disguise? And at that moment, all your tagged drilling offers you nothing.

The engineers who pass interviews have a trained selector, not just trained executors. They can read a problem's constraints and quickly land on the right pattern family before starting to code. This selector is built through untagged, interleaved practice, not through drilling pattern-specific problem sets.

This is also what the research on active recall and recognition points to: recognizing a solution when you see it is not the same as being able to retrieve an approach from a cold problem statement. Most blocked LeetCode grinding trains recognition. Interviews test retrieval.

The most common LeetCode practice mistake is exactly this: treating the category tag as part of the problem. Remove the tag and a large fraction of your "solved" problems would take you significantly longer. You didn't solve those problems. You solved their categories.

Why 100 to 150 Is a Reasonable Target

Blind 75 was built around a specific principle: one representative problem per pattern trigger combination. Cover Two Sum (hash map lookup), Product of Array Except Self (prefix product), Valid Palindrome (two pointers), Longest Substring Without Repeating Characters (sliding window), and so on. Each problem seeds a pattern, not just an answer.

NeetCode 150 extends this by filling real gaps. Tries, bit manipulation, more advanced DP, intervals. Problems 76 through 150 mostly add coverage on patterns underrepresented in Blind 75. This is why 150 is the most common recommendation: it achieves close to full pattern coverage across all 15 core families.

Beyond 150, the math changes. Problems 151 through 300 are mostly more problems within patterns you already have. Some refinement, some edge cases worth seeing. But you're on the steep part of the diminishing returns curve now. The jump from 0 to 150 is a coverage jump. The jump from 150 to 300 is a depth jump within coverage you already have. Depth is valuable. But if you have 60 days before an interview, the first 150 bought you more per hour than the next 150 will.

One caveat matters: 150 problems done wrong (copying solutions, no review, never practicing untagged) is worse than 75 problems done right. The number is a proxy for coverage and depth. A bad process makes it a terrible proxy. You can put 300 problems on your resume header and still walk into an interview unable to identify a sliding window problem.

The Only Readiness Test With Actual Signal

Forget the problem count. Here is a readiness test with genuine signal.

Take five medium problems from patterns you've already studied. Go to LeetCode, filter by difficulty, pick randomly. Turn off category hints. Set a 35-minute timer per problem. No looking anything up. Solve cold.

If you can produce a working solution with correct complexity on three of five, you're ready to interview. If you're failing on two or more, the failure is diagnostic: which patterns are you failing on? Go deepen those specific patterns. Don't add new problems. Fix the gaps.

This cold-solve test measures the exact skill the interview measures, so it's the only readiness signal that directly predicts interview performance. Problem count doesn't do this. Success on problems you've seen before doesn't do this. Cold solving under time pressure does.

This is also where voice practice fills a gap that self-testing can't. At SpaceComplexity, you solve problems out loud under realistic interview conditions with rubric-based feedback on your approach, communication, and edge case coverage. The cold solve tests whether you arrive at a solution. Voice interview practice tests whether you can get there while narrating, explaining tradeoffs, and catching your own bugs. Those are two different and equally necessary things.

The Retention Variable Almost Everyone Ignores

Grinding has an underappreciated problem: the interview tests what you remember, not what you once learned.

You can have a genuinely great prep session where you deeply understand a DP pattern and solve five problems in it. Then you take two weeks off and do other things. The Ebbinghaus curve has deleted most of that. The session happened. The retention didn't. You're showing up to the interview with a ghost of what you knew.

Spaced repetition changes this calculus. Instead of solving problems linearly and moving on, you revisit them at increasing intervals: the day after, a week later, three weeks after. The research is consistent: 80 problems solved and reviewed via spaced repetition outperform 200+ solved once. Not because 200 problems is too many, but because 200 problems solved once gives you exposure, not retention. Exposure evaporates. Retention compounds.

For interview prep, the practical version: when you get a problem wrong or struggle significantly, flag it and re-solve it from scratch a week later with no solution visible. Then again two to three weeks after that. The problems you struggled with are the ones worth revisiting. The ones you solved easily in 10 minutes on the first try are probably fine.

Stop Tracking Problems Solved. Track These Instead.

If you want a dashboard that tells you something real about your readiness:

Patterns covered with at least five genuine practice problems each. Target: 14 to 15 of 15 core patterns.
Cold-solve success rate on unseen mediums in patterns you've studied. Target: 60% or better.
Problems reviewed via spaced repetition (every problem you struggled with, revisited at least twice).
Days since last practice, because recency matters more than your all-time solved count.

Stop tracking total problems solved. It feels satisfying, it goes up every day, and it tells you almost nothing about whether you're ready for an interview next week. The counter going up is not the same as you getting better. Track the things that actually predict performance.