Short answer: for most candidates, a realistic target is 100 to 200 well-chosen LeetCode problems, spread across the core interview patterns and re-solved until they hold up on a timer. Startups and mid-size companies sit at the lower end; big-tech loops, new grads facing online assessments, and anyone starting from scratch sit higher, often 150 to 300. The count is only a proxy — you are ready when you can solve a medium you have never seen in about 30 minutes while explaining your reasoning out loud.
Below is a realistic breakdown by target and starting level, why coverage matters more than the number on your profile, a readiness checklist you can actually test, and an eight-week plan that fits around a job.
How many problems by target company
No company publishes a required number, so treat these as planning ranges, not hiring data. They are built from what the common curated lists contain and what candidates commonly report about each kind of loop. “Problems” here means distinct problems solved properly, not re-solves.
| Target | What coding rounds tend to look like | Realistic range | Where extra time goes |
|---|---|---|---|
| Startup or small company | Varies widely: practical coding, take-homes, debugging, sometimes one LeetCode-style round | 50–100 | Building small features quickly in your main language; APIs and data modeling |
| Mid-size tech company | One or two algorithm rounds, mostly easy to medium | 100–150 | Finishing one curated list end to end, then timed practice |
| Big tech / FAANG | Several algorithm rounds, mostly mediums with some hards; candidates report two problems per round at some companies | 150–300 | Hards in trees, graphs and dynamic programming; company-tagged questions; mock interviews |
| New grad or intern | An online assessment plus coding rounds often make up most of the process | 150–250 | Timed assessment-style sets and speed on mediums |
| Senior (L5+ or staff) | Coding rounds are still common, but system design and behavioral carry more weight | 100–200, often as a refresh | System design and leadership stories; keep coding sharp rather than chasing a count |
Two published reference points help anchor these ranges. Tech Interview Handbook estimates about 30 hours of practice to cover the bare minimum and roughly 100 hours to be well prepared. Grind 75, from the same author, tops out at 169 questions, and its FAQ says the returns on doing questions beyond that list are diminishing. Process details vary by company and team, so confirm the round format with your recruiter before you decide where to spend the hours.
Adjust for where you are starting
Your starting point moves the number more than your target does. Someone who has never implemented a graph search needs different preparation from someone who solved 300 problems two years ago.
| Starting point | What to do first | Adjustment |
|---|---|---|
| New to data structures (no algorithms course, or years away from it) | Learn arrays, hash maps, stacks, queues, trees, graphs, recursion and Big-O before grinding. Do 30–50 easy problems to build fluency. | Add 50–100 to the range above |
| Comfortable with easies, shaky on mediums | Start a curated 75-problem list and work it pattern by pattern. | Use the range as listed |
| Solved 200+ before, rusty now | Do not start a fresh list. Re-solve a curated 75 on a timer, then move to company-tagged questions. | Fewer new problems, many more re-solves |
| Competitive programming background | The algorithms are likely there. Spend the time on talking while coding, readable code and edge cases. | Fewer new problems, more mock interviews |
A useful calibration comes from the Grind 75 FAQ: after 20 to 30 questions, if you still regularly need longer than the recommended time per question, treat that as a sign to review fundamentals and practice easier problems before pushing forward.
Why pattern coverage beats raw count
The exact problem you get in an interview is often new to you, but the techniques behind it repeat. Three hundred problems that lean heavily on arrays and strings will not prepare you for a graph question. A smaller set spread evenly across patterns prepares you for far more of what you might see.
The best public data points the same way. interviewing.io surveyed almost 700 of its users, collected their LeetCode profiles and compared them with how each person ranked in interviews on its platform. Total problems solved correlated with interview performance at 0.27 — a real but modest relationship. Gains flattened at around 500 problems: people who kept going past 500 did only marginally better than those who stopped near it. Hard problems were associated with roughly twice the benefit of mediums. These are correlations from a self-selected group, so read them as direction rather than a formula.
Tech Interview Handbook makes a similar point with arithmetic: at about 30 minutes per question and three hours a day, the average person completes only about 160 questions in three to four weeks and may still not internalize the approaches or remember the problems. Volume without review leaks.
Instead of a total, set a coverage target. Aim for roughly 5 to 10 solid problems per pattern, with more in trees, graphs and dynamic programming because they have the most variants:
- Arrays and hashing
- Two pointers and sliding window
- Stack and monotonic stack
- Binary search, on sorted arrays and on the answer
- Linked lists
- Trees: DFS, BFS and binary search trees
- Heaps and top-K problems
- Backtracking
- Graphs: BFS, DFS, topological sort, union-find
- Intervals and greedy
- Dynamic programming, one-dimensional and grid
- Tries and bit manipulation (a few each)
That works out to roughly 80 to 150 problems. Bigger targets add depth on top of that base, meaning more hards and company-tagged questions, rather than more breadth. Our guide to the core LeetCode patterns explains the trigger and template for each one.
What counts as “done”
A problem only counts toward your number when all four of these are true:
- You solved it yourself, or you read the approach and later re-solved it from a blank editor at least a few days afterward.
- It handles edge cases you wrote: empty input, a single element, duplicates, negative numbers, the maximum input size.
- You can state the time and space complexity and explain where it comes from.
- You can explain the idea in two or three sentences to someone who has not seen the problem.
Amazon’s own SDE II interview prep page is a good reminder of the real bar: it says to expect to write syntactically correct code rather than pseudocode, and it names scalable, robust and well-tested code as its main evaluation criteria. An accepted submission covers only part of that. A solution you copied counts as zero until you re-solve it.
How to tell you are ready
Use signals you can test instead of a counter:
- Unseen mediums in about 30 minutes. Pick mediums you have not seen, from patterns you have studied, and time yourself. The Grind 75 FAQ notes that coding interviews usually give you less than half an hour per algorithm question, and that if you consistently solve its questions in less than the recommended time, you are probably ready.
- Pattern recognition early. Within the first few minutes you can name a likely approach, even if you refine it later.
- Brute force to optimal. You can state a working brute-force solution and its cost, then improve it out loud.
- Talking while coding. You narrate decisions without long silences and state complexity without being asked.
- Self-testing. You trace your code with a small example and catch your own bugs before saying you are done.
- The re-solve test. Pull ten random problems you solved two or more weeks ago and re-solve them on a timer. If most go cleanly, your count is real. If half fall apart, re-solve before adding anything new.
- Mock feedback has stopped repeating. After several timed mocks, the same weakness no longer shows up every time.
The last two signals need practice out loud, not just in an editor. A friend, a recorded session or a free AI mock interview in CoPilot Interview all work; the mock reads each question aloud, you answer out loud, and every answer gets a score with what worked and what to improve.
A weekly plan: eight weeks to about 100 problems
This plan assumes 10 to 12 hours a week, close to the 11 hours a week Tech Interview Handbook suggests for its three-month plan. It is ordered by pattern rather than difficulty and lands around 80 to 100 new problems plus regular re-solves.
| Week | Focus | New problems | Also do |
|---|---|---|---|
| 1 | Arrays, hashing, two pointers | 12–15 | Big-O review; start a pattern log |
| 2 | Sliding window, stack, binary search | 12–15 | Re-solve last week’s misses |
| 3 | Linked lists, trees (DFS, BFS, BST) | 12–15 | First timed set: two problems in 60 minutes |
| 4 | Heaps, backtracking, tries | 10–12 | Re-solve misses from weeks 1–3 |
| 5 | Graphs: BFS, DFS, topological sort, union-find | 10–12 | First mock interview |
| 6 | Dynamic programming, greedy, intervals | 10–12 | First hards in patterns you already know |
| 7 | Mixed timed sets, company-tagged questions | 10 | Two mock interviews |
| 8 | Weak patterns, re-solves | 5–8 | Two or three mocks; ease off before the interview |
A typical weekday takes about 90 minutes:
- 5 minutes: skim your pattern log.
- 60 minutes: two new problems, about 30 minutes each. If you have made no progress after 25–30 minutes, read the approach (not the code), write it yourself and queue it for a re-solve.
- 20 minutes: re-solve one older problem from a blank editor.
- 5 minutes: one line per problem in the log — the clue in the prompt and the technique it maps to.
On weekends, do one timed set of two problems in 60 minutes while talking through your approach, then review everything you missed that week. Lighter weeks later in the plan trade new problems for re-solves and mocks.
Scaling the plan:
- Big-tech target: after week 8, keep adding 10–15 problems a week, weighted toward hards and company-tagged questions. Another four to eight weeks takes you to roughly 150 to 200. The FAANG 8-week prep plan folds in system design and behavioral rounds as well.
- Short on time: compress weeks 1–6 into three weeks at 20 or more hours a week, but keep the re-solves and mocks. They are the first thing people cut and the thing they miss most.
- Want a ready-made list: Grind 75 builds a schedule around the time you have left, while the NeetCode 150 is a fixed list that suits the 150-problem end of the range.
Mistakes that inflate your count without making you better
- Chasing the counter. Easy problems in patterns you already know pad the number and teach nothing new.
- Never re-solving. Without spaced re-solves you end up recognizing problems instead of being able to write them.
- Staying on mediums forever. For big-tech targets, add hards once mediums feel routine. The interviewing.io analysis suggests shifting toward hards after about 100 mediums.
- Skipping a whole pattern. One blank area, often graphs or dynamic programming, can sink a round no matter how many array problems you have done.
- Solving silently. The round tests explanation as much as code. Narrate from week one.
- Starting a new list instead of finishing one. Curated lists overlap heavily, so re-solving the first list on a timer usually helps more than a second list.
Find out if your count is real
Paste a job description and your résumé, set the mix toward coding and technical questions, and a free AI mock interview reads each question aloud and scores your spoken answer. The free plan gives you 15 minutes a day with no credit card.
Try a free AI mock interviewFAQ
Is 100 LeetCode problems enough?
For many startup and mid-size interviews, yes, if those 100 cover the core patterns and you can re-solve them on a timer while explaining your approach. For big-tech loops, plan for more: roughly 150 to 300, including some hard and company-tagged problems.
How many LeetCode problems do I need for FAANG?
There is no official number. This guide's planning range for big-tech loops is 150 to 300 problems, and an interviewing.io analysis found that gains flattened at around 500, with only marginal improvement beyond that. Covering every core pattern and practicing out loud on a timer matter more than hitting a specific count.
How many LeetCode problems should I do a day?
One to three new problems plus a re-solve or two is sustainable for most people preparing alongside a job; the plan above has you doing two new problems on a typical weekday. Going far beyond that tends to produce recognition without recall.
Should I focus on easy, medium or hard problems?
Use easy problems to learn a new pattern, then spend most of your time on mediums. Once mediums feel routine, add hard problems, especially for big-tech interviews; interviewing.io's data associated hards with roughly twice the benefit of mediums.
How long does it take to get ready for coding interviews?
Tech Interview Handbook estimates about 30 hours for the bare minimum and around 100 hours to be well prepared, and recommends about three months at two to three hours a day for thorough preparation. Your starting level and target company can move that a lot in either direction.
Should I memorize LeetCode solutions?
No. You will often get a problem you have not seen, or a familiar one with a twist, so memorized code rarely transfers. Learn the clue and technique behind each problem so you can rebuild the solution from scratch.