TL;DR: For most engineers, 100 to 150 well-chosen problems, organized by pattern, is enough for FAANG-level interviews. A focused candidate with 4 to 6 weeks can be ready with 75. Beyond ~200 problems, returns collapse: you're re-solving patterns you already know while telling yourself it's progress. The number that matters isn't problems solved; it's patterns you can recognize cold.
Every week someone asks me a version of the same question: "I've solved 180 problems, is that enough?" or "My friend did 400 before his Google interview, do I need 400?"
I ran coding interviews and hiring committees at Meta and Microsoft for years, and here is the uncomfortable truth behind the question: I have rejected candidates who solved 500+ problems and hired candidates who solved fewer than 100. The number was never the difference. What the number hides is the difference, and that's what this article unpacks.
But you came here for a number, so let's start with the number.
The short answer, by situation
| Your situation | Problems needed | Timeline |
|---|---|---|
| Interview in 2-4 weeks, know your data structures | ~75, pattern-organized | 2-4 weeks intensive |
| Standard FAANG prep, working engineer | 100-150 | 8-12 weeks at 1-2 hrs/day |
| New grad, weaker DSA foundations | 150-200 (after a DSA refresher) | 3-4 months |
| Senior/staff loops (design-heavy) | 75-100 (coding is table stakes, not the differentiator) | 4-8 weeks alongside system design prep |
| Startups and mid-size companies | 50-100, mostly easies and mediums | 3-6 weeks |
Two footnotes to that table. First, every range assumes the problems are chosen to cover the common patterns, not picked at random; 150 random problems can easily leave whole patterns untouched. Second, the ranges assume the quality bar I'll define below. 100 problems solved properly beats 300 solved the way most people solve them.
Why "how many" is the wrong question
LeetCode currently hosts more than 3,000 problems. Nobody solves them all, and nobody needs to, because interviewers don't have 3,000 questions either. They have a few dozen patterns they test again and again: sliding window, two pointers, tree traversals, graph BFS/DFS, heaps, backtracking, a handful of dynamic programming shapes. Every "new" problem you'll face is one of these patterns wearing a costume.
That reframes the question entirely. You're not trying to have seen the interviewer's exact problem before (you probably won't have). You're trying to build a library of patterns complete enough that whatever they ask maps onto something you know. The question is not "how many problems?" It's "how many problems does it take to make every common pattern automatic?" And the answer to that question has a ceiling, which is why the 100-150 range keeps coming up: with 27 common patterns and 4 to 6 problems needed to internalize each one's range of variations, the arithmetic lands you at roughly 110 to 160 problems. Past that point you're mostly buying repetition of patterns you already own.
I wrote about why this recognition skill, not volume, is the thing interviews actually test in Why Is LeetCode So Hard? The Missing Skill Nobody Teaches.
The diminishing returns curve
Here's roughly how value accumulates when problems are pattern-organized:
- Problems 1-50: steep learning. Every session introduces a new pattern or a major variation. This is where "I can't solve mediums" turns into "I usually have an approach."
- Problems 50-150: consolidation. You're filling coverage gaps, meeting each pattern's harder variations, and building speed. This is where interview readiness actually happens.
- Problems 150-250: polish. Useful if you're targeting the hardest loops (Google, quant firms) or need confidence, but each problem now teaches you a fraction of what problem #40 did.
- Beyond 250: procrastination that feels like work. At this point, more problems is usually avoidance of the scarier, higher-value work: mock interviews, thinking out loud, system design.
The grinder solving problem #437 isn't lazy; they're misallocating. An hour spent on your 437th problem returns almost nothing. The same hour spent doing a timed mock, out loud, in a bare editor, returns a lot, because performance under observation is the half of the interview that LeetCode volume never trains.
What "solved" actually means (the quality bar)
The counts above only hold if a problem meets this bar before you count it:
- You produced the approach yourself, or failed for 30 minutes first. Reading a solution after two minutes of confusion teaches reading, not solving. Struggle is the mechanism, and about 30 minutes of it is the useful dose.
- You can name the pattern and the tell. One sentence: "This was sliding window, and the tell was longest substring with a constraint." If you can't say it, the problem taught you an answer, not a skill.
- You wrote working code, not pseudocode in your head. "I basically knew it" collapses under interview pressure. Type it, run it, fix it.
- You re-solved your failures a week later, cold. A problem you failed, studied, and reproduced from scratch seven days later is worth three problems you got first try. Your failure list is the highest-yield problem set you own.
By this bar, most "400 problems solved" profiles are really 80 problems solved and 320 problems read. That's the gap I saw from the interviewer's chair, and it was visible within ten minutes: candidates who counted by this bar could handle my follow-up variations; candidates who counted submissions could not.
Want the 100-150 chosen for you? Grokking the Coding Interview organizes hundreds of problems into 27 pattern chapters so every problem you solve fills a coverage gap instead of repeating one. On a tight timeline, Grokking 75 is the 75-problem fast path.
How many problems per day?
The second question everyone asks. The answer: 1 to 2 problems a day, sustained, beats 8 problems on Saturday, for the same reason five gym sessions a week beat one five-hour session. Pattern recognition consolidates between sessions; cramming gives it nothing to consolidate.
A schedule that works for a full-time engineer:
- Weekdays: one problem (45-60 minutes: solve, then post-mortem the solution and write the pattern tell).
- One weekend day: two problems from your failure list, plus one timed mock under interview conditions.
- Rest day: actually rest. Retention needs it.
That's 8 to 9 quality problems a week, which puts the 100-150 range at 12 to 16 weeks, or 6 to 8 weeks on the intensive two-a-day version. If your interview is in two weeks, don't try to compress 150 problems into it. Cut the list to one problem per core pattern (roughly 25), spend the saved time on mocks, and walk in with fewer patterns held solidly rather than many held loosely.
What the interviewer actually sees
A last piece of perspective from the other side of the table, because it should change how you spend your remaining prep time. When I graded a candidate, my scorecard had nothing about how many problems they'd done. It asked, in effect:
- Did they clarify the problem before diving in?
- Did they reason toward an approach out loud, and could they justify it?
- Did they write clean, working code and test it themselves?
- When I changed a constraint, did they adapt or collapse?
Problem volume helps with exactly one of those four (having an approach), and only up to the coverage ceiling. The other three are trained by how you practice: out loud, timed, with self-testing, and with follow-up variations. That's why the honest answer to "how many LeetCode problems?" is a number small enough to leave room for the practice that the number can't replace.
The takeaway
Solve 100 to 150 pattern-organized problems to the quality bar: approach produced yourself, pattern named, code written and run, failures re-solved a week later. Use 75 on a short timeline, and stop by 200 to reinvest your hours in mock interviews. LeetCode's problem counter is a vanity metric; your pattern coverage is the real one, and it maxes out far earlier than the grinders want to believe.
Make every problem count: Grokking the Coding Interview: Patterns for Coding Questions teaches all 27 patterns with problems grouped for recognition, in 6 languages, rated 4.6/5 by 62,000+ learners. It's the original patterns course, built by ex-FAANG hiring managers.
FAQs
How many LeetCode problems should I solve for FAANG interviews? 100 to 150 problems organized by pattern is enough for most FAANG loops, assuming solid data structure fundamentals. With a strong foundation and a near-term interview, a curated 75 (like Grokking 75) is sufficient.
How many LeetCode problems should I do a day? One or two, done properly: attempt for up to 30 minutes, study the solution as a post-mortem, and write down the pattern's tell. Daily consistency beats weekend bingeing because pattern recognition consolidates between sessions.
How many LeetCode problems are there in total? Over 3,000, growing weekly. This is exactly why counting problems is hopeless and covering patterns is the only strategy that scales: a few dozen patterns generate nearly all of them.
Is 200 LeetCode problems enough? Almost always, and usually more than enough. If you've solved 200 pattern-organized problems to a real quality bar and still feel unready, the gap is interview performance (thinking aloud, time pressure, follow-ups), not problem count. Shift your hours to timed mocks.
What ratio of easy, medium, and hard problems should I solve? Roughly 20% easy, 65% medium, 15% hard. Real interviews live at the medium level. Easies build momentum at the start of each pattern; hards matter mainly for the toughest loops, and only after mediums feel routine.