The rules of practice

The time box

On this one thing the entire canon agrees: you do not stare at a problem indefinitely, and you do not give up in five minutes. The consensus window before you are allowed to read a solution is 20 to 45 minutes of genuine effort. The Tech Interview Handbook, the Blind 75 thesis, and every serious retrospective land somewhere inside that band.

The real disagreement is about the floor, and it is worth understanding because the two camps are optimising different things. The struggle camp says the productive confusion before you crack a problem is where learning happens, so quitting early throws away the expensive part. The spaced-repetition camp counters that one hour spread over four days beats four hours in one sitting, so a shorter box plus a guaranteed revisit extracts more learning per hour than a long heroic session. Both are right about their own variable. The plan splits the difference: box at 35 minutes, but treat the revisit schedule below as non-negotiable, because the short box only works if the problem actually comes back.

How to read a solution so it sticks

Reading a solution and nodding along is the named failure mode in every guide that bothers to name failure modes. The solution makes sense, you feel the click, you move on, and two weeks later you cannot produce it. The click is recognition, not recall, and interviews test recall.

Reading a solution correctly has three steps, and the first is the only passive one:

1. Read for the idea, not the code. What is the core insight? "Sort first, then two pointers." "The window only ever grows or slides." Write that one sentence down. If you cannot compress the solution to a sentence, you have not understood it yet.
2. Close it and re-implement cold. Same day, blank editor, no peeking. If you get stuck, you are allowed one more look, then blank editor again. The gap between "I followed it" and "I can produce it" is exactly the gap this step closes.
3. Explain it back. Out loud or in writing, to nobody: why does this work, and what category of problem does it crack? The explanation is what your memory will index on later, when a disguised version shows up.

The revisit schedule nobody gives you

Every guide says "review your old problems." None of them say when. Here is a concrete schedule, triggered by how the first attempt went, so the problems that need the most reinforcement get it and the ones you owned do not waste your time:

A redo means a blank file and the full time box, not skimming your old code. If a redo fails, the problem re-enters the queue at the harsher tier. Keep the queue anywhere that survives a bad week: a text file, a spreadsheet, index cards. The tooling does not matter; the trigger discipline does. On any given day, the queue gets served before new problems do.

Talk while you solve, from problem one

Here is the trap built into every problem list ever published: the list trains you to solve silently, then the mock interviews scheduled for the final month discover you cannot narrate. By then you have hundreds of hours of silent habit to unlearn, during the weeks you can least afford it.

So narrate from problem one. Literally the first easy problem you ever attempt: say what you are trying, why, and what you expect to happen, out loud, alone in the room, feeling ridiculous. The cost is nearly zero. The compounding is enormous, because by interview season narration is not a skill you perform, it is just how you solve. As a bonus, talking surfaces your own confusion early; it is rubber-duck debugging applied to your own reasoning. The interview warmup routine assumes this habit already exists. Build it now so that page has something to warm up.

Track why you failed, not how many you solved

A solve count tells you how busy you were. A log of whys tells you what to fix. When a problem beats you, write one line classifying the failure:

• Mechanical. Off-by-one, wrong loop bound, fumbled index arithmetic. The idea was right; the fingers were not. Fix: slow down at boundaries, test the edges first.
• Wrong invariant. You had the right pattern but maintained the wrong property: the window held the wrong thing, the stack stored the wrong element. Fix: state the invariant in words before writing the loop.
• Wrong pattern pick. You reached for binary search when it was two pointers, or DFS when it was a heap. Fix: this is a recognition gap, and it tells you which pattern in the pattern catalogue needs more examples.

After a few weeks the log develops a shape, and the shape is your actual curriculum. Most people discover their failures are 70% one category, which means most of their practice should be aimed at one category. Nobody discovers this from a streak counter.

The exit criterion

Every guide defines a start. None define done, which is how people end up doing problem number 612 out of anxiety. So here is a definition of done for the problem-solving portion of this plan, borrowed from what interviews actually demand:

When you pass that bar, more grinding is hoarding. Maintain with a few problems a week and spend the reclaimed hours on the later tasks, which is where most candidates are actually thin. When you fail the bar, the failure itself tells you what to practice; feed it through the taxonomy above.

Volume is the universal regret

Read enough retrospectives and one regret repeats until it stops being anecdote: people did too many problems, too shallowly. The genre's cautionary classic is the candidate who ground through 847 problems and failed every interview anyway; the diagnosis in that post, and in the hundreds of replies agreeing with it, was pattern matching by muscle memory with no transfer to unseen problems. At the other pole, jwasham wrote of his famous multi-year curriculum, "I simply over-prepared," and the Blind 75's entire thesis is that a small, well-chosen set covers the territory.

Roughly 150 right problems in the right order beat 1,000 in whatever order the filter spat out. Or as the line that shows up in one retrospective after another goes: the fifty I went deep on got me through. The depth, in case it needs saying, comes from the rules above: the box, the cold re-implementation, the revisit queue. Volume was never the variable. The problem-solving methodology page goes deeper on what deliberate practice means here; task 5 will put it to work.

Further reading

• Tech Interview Handbook — coding interview study plan — the best of the free canon; note how its advice on solutions matches step two above.
• The original Blind 75 post — the argument for a small curated set, from the person who curated it.
• jwasham — coding-interview-university — read the intro for the "I simply over-prepared" retrospective, not the list for the list.