How many LeetCode problems are enough?
How many LeetCode problems are enough before an interview? Around 100 to 150, chosen to cover the core patterns, beats 500 picked at random. The number that predicts your interview result is not problems solved; it is patterns you can recognise and re-derive cold. Here is how to count that instead.
Around 100 to 150 problems, chosen deliberately, is enough for most engineers facing a standard technical loop. That number assumes coverage of the core patterns with a handful of variations each, and honest re-solving rather than solution-reading. Grinding 500 random problems is neither necessary nor sufficient; I have watched both failure modes in real interviews, from both sides of the table.
The question itself contains a trap, and I want to defuse it before defending the number. Asking "how many problems" is like asking how many tests a codebase needs. Fifty tests that each exercise a distinct behaviour beat five hundred that all hit the same happy path. The unit that matters is not the test but the behaviour covered. Interview preparation has the same structure: the unit that matters is the pattern, and problems are just probes against it.
Why does problem count predict so little?
Because solved-once is not the same as retrievable under pressure. An interview gives you 35 to 45 minutes, a person watching, and a problem you have probably not seen verbatim. What saves you is recognising the shape ("this smells like a sliding window over a constraint") and re-deriving the mechanics from a model you actually hold. A problem you solved four months ago by peeking at the editorial contributes almost nothing to that; it sits in your count and not in your head.
Counts also inflate on easy duplicates. Two hundred array-iteration easies teach the same loop two hundred times. The marginal problem in a category you already own is worth close to zero, while the first three problems in a category you have never touched are worth more than any ten repeats. Diminishing returns arrive per pattern, fast, and a raw count is blind to them.
What should you count instead of problems?
Two numbers: patterns covered, and recall depth per pattern. The core interview canon is smaller than the grind mythology suggests; the working list on this site is nine modules and roughly two dozen recurring shapes, catalogued in the interview patterns essay. For each one, ask three questions of yourself. Can I state when the pattern applies and when it breaks? Can I write the skeleton from a blank editor, no reference? Have I solved at least one variation that twisted it?
A pattern that passes all three is owned; further problems there are maintenance, not progress. A pattern that fails the second question is where your next five problems should go. This is a coverage metric, and like test coverage it tells you where the untested code is. The count of 100 to 150 is simply what this coverage costs in practice: roughly two dozen shapes, times three to five problems each, plus a margin of genuinely hard mixed problems that force you to choose a pattern rather than be told one.
How do the common milestone numbers compare?
The numbers people trade on forums are not meaningless; they just measure different things. Here is what each regime actually buys, assuming problems are chosen rather than random:
| Problems | What it can cover | Where it fails |
|---|---|---|
| ~50 | The high-frequency patterns once each: arrays, hashing, two pointers, BFS/DFS, basic DP | No variation depth; a twisted prompt breaks the memorised form |
| 100 to 150 | All core patterns with 3 to 5 variations each, plus mixed hard problems | Specialised loops (heavy graph theory, string algorithms at depth) |
| 300+ | Broad recall across niche categories; speed from sheer familiarity | Time. Months of grind, steep diminishing returns, and staleness sets in anyway |
Note what the table is quietly claiming: the middle row is a knee in the curve, not a compromise. Past it, each additional problem mostly re-covers owned ground. Before it, whole categories are dark. The 300-plus regime exists for competitive programmers and for candidates targeting the few companies that ask genuinely exotic questions, and even there the extra problems chase the tail, not the core.
What does a 100-problem plan actually look like?
Work through patterns in dependency order, not difficulty order. Arrays and hashing before two pointers, trees before graphs, recursion before dynamic programming; the curriculum page lays out one such ordering with the prerequisites made explicit. For each pattern: read the concept properly once, solve two or three mediums without hints, then one variation that breaks the template. When you stall, stall honestly for twenty minutes before reading a hint, because the stall is where recognition gets trained; the shape-recognition essay argues this mechanism in detail.
Then schedule decay. A pattern solved three weeks ago has already blurred, so re-solve one old problem per day cold, from a blank file. This is cheap (you own the pattern, so it takes ten minutes) and it converts your count from "problems ever solved" into "problems solvable today", which is the only number the interview measures. Fifteen minutes of daily maintenance holds roughly a hundred problems' worth of coverage indefinitely.
One more honest caveat: this arithmetic covers the coding rounds. System design, behavioural rounds, and the deduction-style warm-ups some firms still open with are separate preparations; for the last of those, a daily puzzle is the right-sized rep.
Frequently asked questions
Is 50 LeetCode problems enough for an interview?
For an internship screen or a single well-known company whose question style you have researched, sometimes. For a general loop, 50 covers each core pattern about once, which leaves you memorising forms rather than owning them. The first twisted prompt exposes the difference.
Do I need to solve hard problems?
A few, late, and for a specific reason: hards force pattern selection instead of pattern execution. Most companies interview at the medium level, so the bulk of your set should be mediums. Ten well-chosen hards after your patterns are covered beat fifty attempted before.
How long does 100 to 150 problems take?
At one to two problems a day with re-solving mixed in, eight to twelve weeks. Compressing it into three weeks of cramming produces a count without retention; the decay schedule is the part that makes the number stick.
If you are starting the plan today, begin where the dependencies begin: Module 01, arrays and sequences.