How Much Coding Interview Practice Is Enough? What the Data Says

For most engineers, 100 to 150 problems is enough. The problems must be chosen to cover the common patterns. Each one must be solved with a timer running.

The count matters less than most people expect. The interview platform interviewing.io matched a survey of almost 700 users against more than 100,000 real and mock (practice) interviews. Problems solved correlated only 0.27 with the result, and gains past about 500 problems were marginal.

This article gives the ranges by situation, explains what the data shows, and defines what makes one solve count. It ends with a readiness test and a plan for the final week.

How many problems you need, by situation

A pattern is a reusable approach that solves a whole group of questions. Sliding window, two pointers, and breadth-first search are patterns.

The ranges below assume two things. The problems are grouped by pattern, and each solve meets the quality conditions described later in this article.

Random problems do not produce these results. A set of 150 problems picked at random can leave out whole patterns. Choose one list that is organized by pattern, then finish each pattern before starting the next.

What the interviewing.io data shows

The numbers below come from interviewing.io's analysis of LeetCode practice and interview performance. It surveyed almost 700 of its users and matched their answers against performance data from more than 100,000 real and mock technical interviews. Four findings matter here, and they use LeetCode's labels of easy, medium, and hard.

Each extra problem adds a small, steady gain. Each additional 50 medium problems raised the interview pass score by about three percentage points. Each additional 50 hard problems raised it by about seven points.

Hard problems teach more per problem. About 233 medium problems were needed to match the benefit of 100 hard ones.

A hard problem is often a known pattern with one extra constraint. Solving it teaches more about the pattern than another medium does.

Gains become marginal, meaning very small, at about 500 problems. Most top performers in the data stopped around 500 problems. Gains beyond that point were marginal.

The count predicts little on its own. The total number of problems solved correlated 0.27 with interview percentile. Percentile is a candidate's rank among all candidates measured.

A correlation of 1 would mean the count predicts the rank completely. A correlation of 0 would mean no link at all. At 0.27, most of the difference between candidates is explained by something other than the count.

LeetCode contest ratings showed no correlation with interview performance. A contest rating measures speed in timed online competitions, and that speed is a different skill.

Together, these findings mean two things. Solving more problems helps, but slowly, and the gains are marginal past about 500. Most of the result is explained by how each problem is practiced, not by how many.

Why the problem count is the wrong unit

Interviewers do not choose from thousands of questions. They reuse a few dozen patterns, and each question is one of those patterns with new details.

Sliding window, two pointers, merge intervals, tree breadth-first search, and topological sort are on that short list. The full set is described in the coding patterns behind LeetCode questions.

So the useful unit is pattern coverage. Coverage means the number of common patterns you can recognize in a new question and solve without help.

About four or five problems per pattern is enough to learn its main variations. A few dozen patterns at four or five problems each gives the 100 to 150 range.

This is also why the popular curated lists are all short. A curated list is a small set of problems that someone chose so that each common pattern appears a few times.

None of these lists has more than 169 problems. Their authors could choose from thousands of problems and chose fewer than 200.

Which list you use matters less than finishing one list by pattern. Blind 75 or coding patterns explains how to choose between a fixed list and a pattern course.

Grokking the Coding Interview teaches the patterns one at a time. The problems for each pattern are grouped, so every new problem adds a variation you have not seen.

What counts as a solved problem

The ranges above only work if a problem meets four conditions before you count it. Most misleading counts come from reading a solution after five minutes and marking the problem done. A problem counted that way taught you an answer, not a skill.

Solved within the time limit. Set a timer for 25 minutes on a medium problem and 35 on a hard one. If the timer ends first, add the problem to your failed list, even if you finish it later.

Explained aloud. Say the approach before you write it, then keep talking while you code. In the interview, the interviewer only hears the reasoning you say out loud, so practice saying it.

The pattern named before coding. Write one sentence with the pattern and the words in the question that identified it. For example: "Sliding window, because the question asks for the longest substring under a constraint."

Re-solved from memory a week later. Seven days after the first attempt, solve the problem again without notes. A problem that passes this second solve is counted, and one that fails is added to the failed list again.

A failed problem is not wasted time. It shows you exactly which pattern or variation you do not know yet.

A readiness test you can run today

This test takes about two and a half hours and answers the question for you.

1. Pick five medium problems you have not seen, from five different patterns.
2. Start a timer. Within two minutes, write down the pattern you would use.
3. Say the approach out loud, then solve the problem within 25 minutes. Write three test cases of your own in that time.
4. Repeat for the other four problems.

A problem passes on two conditions. The pattern named in two minutes was correct, and the code passed your tests within 25 minutes.

Four or five passes out of five means you are ready. Spend the remaining time on mock interviews rather than on new problems.

Two or three passes means the count is not the issue, so look at each failure. If you named the wrong pattern, study that pattern's signals. A signal is a phrase in the question that identifies the pattern.

If you named the right pattern but the timer ended first, the issue is speed. Solve more problems in that pattern with the timer on.

Zero or one pass means you do not know the fundamentals well enough yet. Do a data structures review first, then start the pattern list again.

Hours per week versus problem count

Hours are a better planning unit than problems, because a problem done properly takes a predictable amount of time.

Plan on about 40 minutes for a new problem. That is 25 minutes to solve it and 15 to review the solution and write the pattern sentence. A re-solve from the failed list takes about 15 minutes, and a mock interview takes about an hour.

The middle row is the standard plan for a working engineer. At about 90 minutes a day, 100 to 150 problems take 8 to 13 weeks. Ninety minutes on six days works better than nine hours on Saturday.

Memory for patterns improves between sessions, so six short sessions teach more than one long one. Keep one rest day a week.

When mock interviews replace more problems

A mock interview is a timed practice interview with another person. That person asks a question, watches you code, and asks follow-up questions. It trains what solving alone never trains: explaining while coding, handling a changed constraint, and working while someone watches.

The problem count measures none of those, which is one reading of the 0.27 correlation above.

Spend most of your hours on mocks instead of new problems when three things are true:

• You pass the readiness test with four of five.
• Your failed list has fewer than ten problems on it.
• Your recent failures came from time or nerves, not from an unknown pattern.

From that point, a good week is two mocks plus re-solves from the failed list, with no new problems. Colleagues, peer-matching platforms, and paid interviewers all work.

A mock with a stranger is more useful than one with a friend. A friend will help when you stop, and a stranger will not.

If your target company runs a coding round with an AI assistant, add one mock in that format. The AI-assisted coding interview explains how that round differs from the classic one.

What to do in the final week

Learn no new patterns in the last seven days. A pattern first seen this week will not be reliable in the interview.

• Re-solve every problem on your failed list once, from memory, with the timer on.
• Read your pattern sentences once a day, so you keep recognizing each pattern's signal quickly.
• Do two or three mocks on different days, and expect the first one to be the weakest.
• Test the setup: the shared editor, your camera and microphone, and the language you will code in.
• Stop early the night before and sleep. On the morning of the interview, solve one easy problem, so the first code you write that day is not in the interview.

For a short timeline, Grokking 75 collects the most common interview questions, grouped by pattern. It fits a plan of two to four weeks.

Frequently asked questions

Is 100 LeetCode problems enough for a coding interview? Yes, for most working engineers with solid data structure basics. The 100 must include every common pattern and be solved with a timer, then explained aloud. For the hardest interviews, solve 150.

Is 500 problems too many? Usually, yes. In interviewing.io's data, most top performers stopped around 500 problems and gains beyond that were marginal. Hours past about 150 problems are better spent on mock interviews.

How many problems should I solve a day? One or two, on most days. A new problem takes about 40 minutes when you solve it, review it, and write the pattern sentence. Daily practice with one rest day works better than a long weekend session.

Should I solve hard problems or only mediums? Mostly mediums, then hards in a pattern once you solve its mediums within the time limit. In interviewing.io's data, 50 hard problems raised the pass score by about seven points, against about three for 50 mediums. Hard problems teach more per problem, but most interview questions are at the medium level.

Is Blind 75 enough? For a candidate with two to four weeks and solid basics, a 75-problem list organized by pattern is enough. Any of the short curated lists works if you finish it pattern by pattern and meet the quality conditions. With more time, extend to 100 to 150 problems.

How long does it take to prepare for a coding interview? About 8 to 13 weeks for a working engineer at 90 minutes a day. Two to four weeks with solid basics and a 75-problem list. A new graduate needs longer, because the data structures review comes first and the list is 150 to 200 problems.

Related reading

• Is Grinding LeetCode Enough for Your Interview Prep?
• Don't Just LeetCode
• Blind 75 or Coding Patterns: Which Should You Study First?
• The Coding Patterns Behind LeetCode Questions
• How Long Does It Take to Finish a LeetCode List?
• The AI-Assisted Coding Interview at Meta, Google, and LinkedIn