Two engineers prep for the same cycle. One solves more than 500 problems and freezes when the medium doesn't look like anything from the practice list. The other solves a fraction of that and works the problem out from scratch on the screen. The variable that decides which way it goes isn't volume.
TL;DR
- Volume practice builds memory of specific problems. It builds little of the skill that recognises which technique applies to a problem you've never seen.
- Learning science calls these near transfer (familiar problems) and far transfer (unfamiliar ones). Volume practice mostly trains near transfer.
- Real interviews test far transfer because the problem isn't labelled and won't match anything in the practice bank.
- Recognition is trainable. The training is explicit: read the problem for triggers, name the pattern, then write code.
- On the next problem you face, the recognition pass takes 30 seconds before you touch the keyboard. That pass is the gap.
Disclosure up front: I built Codeintuition, a structured learning platform for coding interviews. This post is about the recognition skill that decides whether volume practice converts to interview readiness, not about the product. The closing link goes to the longer version on my own blog.
What 500 problems actually trains you to do
Most coding interview advice tells you to solve more problems. There's a real reason this advice exists. Volume builds fluency: you stop being confused by syntax, you stop misreading constraints, and the interview minutes that used to go to typo-hunting start going to the actual problem. Past a few hundred problems, those skills are usually solid.
What volume doesn't reliably build is the ability to read a problem you've never seen and decide which technique applies. That's a different skill, and the way most engineers practise actively trains around it. You attempt the problem, get stuck, glance at the LeetCode tags, notice it says stack, and read a solution. The next time a stack problem shows up, you might recognise it. The time after, you might not. Recognition is being built by accident, not by design.
In an interview the tag is gone. The problem statement isn't labelled stack or sliding window or dynamic programming. So the skill that's been built by accident has to do work it's never been explicitly trained for. That's where the freeze comes from.
Near transfer vs far transfer
There's a useful piece of language for this from the learning sciences, and it's worth borrowing because it predicts the failure mode precisely.
Near transfer is when you can solve a problem because it resembles one you've practised. You solved Two Sum with a hash map. The interviewer hands you Two Sum II with a sorted array. The visible details changed but the underlying idea is close enough that recognition fires.
Far transfer is when you can solve a problem that doesn't resemble anything in your practice set, by reading the structure of the problem and constructing the approach from first principles. You see "minimum window of an array containing all characters of a target string" and you've never solved a window problem with a character constraint. You read the structure and construct a variable sliding window from scratch.
Grinding 500 problems builds near transfer well. It does much less for far transfer. Whether far transfer is reliably teachable is a debate the
Which technique's features finally clicked for you only after seeing it on a problem the explanations had skipped?
SOCIAL SHARE CARD GENERATOR