Most people don’t fail the coding interview because they couldn’t solve the problem. They fail because their plan assumed twenty free hours a week and they had six. Three weeks in they’re behind, demoralized, and grinding random Hard problems at 11pm with no system, which is the worst possible use of the little time they’ve got.
So before you pick a problem list, count the hours. Real ones, the kind your calendar actually protects, not the aspirational version where you study every evening after a full day of work and never skip. Look at the last month of your life and assume the next month looks the same. If the real number is six hours a week, build for six. A plan you finish at eighty percent beats a plan you abandon at thirty.
Start from your calendar, not the problem list
The usual mistake is backwards: pick Blind 75 or NeetCode 150 first, then try to cram 150 problems into whatever weeks are left. Do it the other way. Your time budget decides the list, not the reverse.
Here’s the arithmetic people skip. A fresh Medium takes a rusty engineer 30 to 50 minutes to solve, and that’s before you re-read the editorial, look at a cleaner solution, and write down what you missed. Add review and you’re closer to an hour per genuinely new problem. At six hours a week, that’s six to eight new problems, not the twenty you penciled in. Plan for the real throughput and the schedule stops lying to you.
Match the list to the runway you have:
| Weeks until the loop | List that fits | Realistic weekly load | What to drop |
|---|---|---|---|
| Under 4 | Blind 75, or a 50-problem cut of it | 15-25 problems/week, patterns only | Hard problems, niche topics like tries and advanced graphs |
| 4 to 8 | Grind 75 sized to your weeks, or a NeetCode 150 subset | 10-15/week | Most Hards, deep DP |
| 8 to 12 | Full NeetCode 150 | 12-15/week | Nothing major, just pace it |
| 12+ | NeetCode 150 plus weak-topic deep work | 10/week, more re-solving | Boredom; keep it varied |
NeetCode 150 is built for the long runway. It widens Blind 75 across eighteen topics, including greedy, advanced graphs, and 2D dynamic programming, and at ten hours a week it eats ten to twelve weeks. Push to fifteen or twenty hours and you can compress it to six to eight. Blind 75 is the short-runway answer: at five problems a day with re-solves folded in, it’s a three to four week job, and its seventy-five problems still touch every pattern that matters. If you have under six weeks, that’s the one.
Patterns beat problem counts
The number that decides interviews isn’t problems solved. It’s patterns you recognize cold. Roughly fifteen of them cover the large majority of what gets asked: sliding window, two pointers, fast and slow pointers, monotonic stack, the binary search variants, BFS and DFS on trees and graphs, backtracking, top-k with a heap, merge intervals, union-find, topological sort, and 1D and 2D dynamic programming. When you can look at a new prompt and think “sorted input, two pointers” inside the first minute, you’re close to ready. When you’re on problem 140 and still can’t say why a solution works, you’re collecting stats, not skills.
So study by pattern, not by list order. Sit with one pattern and do four to six problems in a row, easy to medium, until the shape stops surprising you. Then move to the next. Bouncing between a graph problem, a DP problem, and an interval problem in the same hour feels productive and teaches almost nothing, because you never give any single pattern enough reps to stick.
Re-solve, or you’re renting the knowledge
The problem you solved on Monday and never opened again is gone by interview day. This is the part everyone underbudgets. Tag every problem the moment you finish it: clean, solved-with-hints, or couldn’t. Then schedule the back two buckets to come back around, once after about three days and again after ten. Spaced repetition is boring and it is the highest-return hour in the whole plan.
Concretely, about a third of your weekly hours should go to re-solving, not new problems. People resist this because new problems feel like progress and re-solving feels like treading water. It isn’t. The candidate who has truly internalized seventy problems will out-interview the one who has speed-run two hundred and forgotten half. If protecting your re-solve time means doing fewer new problems, do fewer new problems.
Timed reps under the real constraint
A problem you cracked in ninety relaxed minutes with editor autocomplete is not a problem you can do in a 45-minute interview while narrating your thinking to a stranger. Those are different skills, and the second one only comes from practicing under the second one’s conditions.
Once your pattern coverage is decent, shift a chunk of your week to timed sessions. Set 45 minutes. Read the prompt, ask your clarifying questions out loud as if someone’s there, code it, walk your own test cases, all on the clock. Better still, book mock interviews on interviewing.io or Pramp, or trade rounds with a friend who’ll actually push back. The first few are rough. You’ll freeze, you’ll go quiet while you think, you’ll forget to test. Far better that happens in a mock than in the round that decides your offer.
Have a rule for when the week falls apart
It will. A deadline lands, you get sick, a kid gets sick, the week evaporates. The people who get through prep aren’t the ones with iron discipline. They’re the ones whose plan degrades gracefully instead of collapsing.
Write the triage rule down before you need it: when you lose a week, do not try to claw it back by doubling up the next one. That just buries you. Drop new problems to zero and spend whatever scraps of time you have only on re-solving your “couldn’t” pile. Defending the pattern recognition you already built is worth more than chasing new coverage you’ll forget anyway. One protected hour of review keeps you in the game, while a guilt-driven attempt to do fourteen problems in a weekend just teaches you to dread the whole thing.
The other thing to cut first is difficulty. Most real loops are mediums. A handful of shops push harder, the quant and high-frequency-trading firms and a few of the AI labs, but for the median big-tech style interview, fluent mediums carry you most of the way. If you’re short on time, a clean Medium you can finish and explain beats a Hard you half-remember.
One concrete week, six hours
To make it less abstract, here’s what a tight week looks like at six hours. Two ninety-minute blocks on new pattern work, one pattern per block, four problems total. One hour re-solving last week’s misses. One hour on a single 45-minute timed problem plus reviewing how it went. Half an hour writing down, in your own words, the trigger that tells you to reach for each pattern you touched. That last thirty minutes feels optional and is the part that compounds.
If laying all of this out by hand sounds like more planning than studying, that’s a fair complaint, and you can hand it off. The free generator at /study-plan/ sizes a week-by-week schedule to your actual timeline and weights it toward the patterns you’re weakest on, so you can spend the hour you’d have spent on spreadsheets actually solving something.
Practice the behavioral round:
