“How many problems should I solve?” is one of the most common questions during interview prep. Answers range from 100 to 1000, but the number alone does not mean much. Solving fewer problems with real understanding is far more effective than rushing through many without learning how the solutions work.

The focus is not the count. The focus is how each problem is approached and what is retained afterward. The goal is to be able to rebuild a solution from first principles, even weeks later, instead of relying on vague memory.

This chapter focuses on the practice process: how long to struggle before checking a solution, how to learn from problems that were not solved, how to revisit problems so they stick, and how to judge when preparation is enough. The aim is to help get more learning out of every hour spent practicing.

“Just solve more problems” sounds like good advice, but it often leads to the wrong kind of practice.

Consider two approaches. One person solves 500 problems in six months. Each problem gets a quick attempt, then the solution is checked, copied, and submitted. Progress feels fast because the solved count keeps increasing.

Another person solves 200 problems in the same time. Each problem gets real effort. Different approaches are tried. Solutions are only checked after getting stuck, and even then, they are studied and re-implemented from scratch.

The second approach consistently leads to better interview performance.

The difference comes down to learning versus completing. Copying a solution after a few minutes skips the hardest and most valuable part of the process. Without that struggle, the underlying idea does not stick. It becomes easy to recognize a problem but hard to solve it independently.

Volume still matters. Enough problems are needed to recognize patterns and build fluency. But depth matters more. A smaller set of well-understood problems builds far stronger intuition than a large set completed mechanically.

One of the hardest decisions during practice is knowing when to stop struggling and look at the solution. Spend too little time and you rob yourself of the learning that comes from struggle. Spend too long and you waste hours going in circles, getting frustrated, and burning out.

The sweet spot for most people is 25 to 30 minutes of genuine effort before looking at a solution.

This window works well because of how thinking typically unfolds. The first few minutes go into understanding the problem and exploring examples. The next phase is where ideas are tested, mistakes happen, and approaches evolve. That middle stretch is where most of the learning happens. After around 30 minutes without meaningful progress, returns tend to drop.

How to spend those 25-30 minutes wisely:

The key phrase here is "genuine effort." Staring at the screen is not genuine effort. You need to be actively trying things: drawing out examples, testing ideas on paper, writing pseudocode, considering different data structures. If you are actively working and making some progress (even slow progress), keep going beyond 30 minutes. The timer is for when you are truly stuck with no new ideas.

Looking at a solution is not the end of the process. It is where the real learning begins. Simply reading it and thinking “that makes sense” creates a false sense of understanding. Recognition is not the same as recall.

A more structured approach helps turn a failed attempt into something that sticks.

Step 1: Read and understand every line

Avoid skimming. Go line by line and understand why each part exists. If the solution uses a technique you do not know (like monotonic stack or union-find), pause and learn that concept before moving forward.

Step 2: Identify the key insight

Every problem has one or two "aha" moments, the observations that make the solution possible. Maybe it is "if I sort the array first, I can use two pointers." Maybe it is "I can use a hash map to track what I have seen." Capture that idea in simple terms.

Step 3: Re-solve from scratch

Start fresh and rebuild the solution using only the key insight. If something breaks or feels unclear, that gap points directly to what was not fully understood.

Go back and study just that part, then close and try again.

Step 4: Explain the solution out loud

Walk through the solution as if teaching someone else. Focus on the idea, the steps, and why it works. Difficulty explaining usually means something is still missing.

This loop may feel slower, but it builds real understanding. Over time, it becomes much easier to recall and apply the same ideas in new problems.

Solving a problem once does not mean it will be remembered later. Without reinforcement, most of that understanding fades quickly.

Spaced repetition is a learning technique where you review material at increasing intervals. The idea is simple: review something just as you are about to forget it, and each successful review pushes the next review further into the future. It is one of the most efficient ways to move information from short-term to long-term memory.

Here is a simple schedule that works well for coding practice:

You do not need to re-solve every single problem three times. Focus your spaced repetition on problems that meet one of these criteria:

A lightweight tracking system helps. A simple sheet with problem name, last solved date, and difficulty is enough. Problems that continue to feel hard across reviews usually point to a missing fundamental, which is worth addressing separately.

When you are learning a new pattern like sliding window or binary search on answer, how many problems do you need before you "own" the pattern? The answer varies by pattern complexity, but a good minimum is three problems per pattern at each difficulty level.

Here is why three works. The first problem teaches you the pattern mechanics, the basic template and how it works. The second problem forces you to adapt the template, because no two problems apply a pattern identically. The third problem is where recognition clicks. By the third problem, you start to see the pattern before you even think about it. Your brain has enough examples to generalize.

For the core patterns that appear most frequently in interviews, here is a recommended problem count:

Notice that this adds up to roughly 90 problems for core patterns. Add in some extras for less common patterns and company-specific favorites, and you land around 120 to 150 problems for solid coverage. If you can deeply solve 150 problems across all major patterns with spaced repetition, you are well-prepared for most coding interviews.

Without tracking, you have no way to know where your weak spots are or whether your preparation is actually working. You do not need anything fancy. A simple spreadsheet works.

Track these columns for every problem you solve:

The most important column is "Solved independently?" Be brutally honest with yourself. If you peeked at a hint, that is a "Partial." If you looked at the solution, that is a "No." There is no shame in either, but lying to yourself defeats the entire purpose of tracking.

After a month of tracking, patterns emerge. Maybe you nail every sliding window problem but struggle with dynamic programming. Maybe you solve mediums fine but hard problems consistently stump you at the same step. These patterns tell you exactly where to focus your remaining study time.

There is a point where solving more problems stops making you meaningfully better. Recognizing this point is important because over-grinding leads to burnout, and burned-out candidates perform worse, not better.

Here are signs you have hit diminishing returns:

When you reach this point, shift your focus. Instead of solving more new problems, spend your time on mock interviews, reviewing problems you previously struggled with, and practicing your communication skills. The marginal value of problem 300 is much lower than the marginal value of your 5th mock interview.

A reasonable stopping guideline by experience level:

Senior and staff engineers often need fewer problems because interviews weigh system design more heavily. But the problems they do practice should skew harder, and their coding needs to be clean and fast to leave time for design discussions.