Twenty patterns,
one offer

The single highest-leverage decision in interview prep is not which problems you solve; it's when you re-solve them. Memory for problem shapes decays fast — a pattern that felt automatic on Tuesday is fog by Sunday unless it gets touched again. So the loop is deliberately boring:

• One pattern per day. Not three. Recognition wires one shape at a time.
• Three problems: one review + two new. The review problem is from yesterday's pattern, solved cold, naming the pattern out loud before typing. That one problem is the spaced repetition doing its job.
• Out loud, every time. If you practice silently, you are rehearsing for a different exam than the one you'll sit.

A full lap of the map — hashing (ch. 4) through bits (ch. 22) — is nineteen study days. With a second review lap and weekly mocks, six weeks at about an hour a day covers everything twice. That is the entire quantitative ask. The Blind 75 exists precisely because 75 well-chosen problems fit this loop with room to spare.

The loop only works attached to a calendar, and the calendar only works built backward from the interview date. The scheduler below does the arithmetic: give it your weeks and your weekly hours, and it lays out the pattern rotation (green = first-lap study day, ochre = second-lap review), converts one day a week into a timed mock from week two on, and tapers the final two days. Every study day silently includes the "one review problem from yesterday" rule.

Play with the sliders and notice the failure mode: two weeks at three hours doesn't cover the map, no matter how the days are shuffled. When the verdict goes red, the honest fixes are more weeks or more hours — not faster reading. And notice the opposite: past six or seven weeks the second lap fills up and extra time buys very little, which is the coverage curve from Chapter 1 wearing a calendar costume.

Solving problems trains the algorithm. Only mocks train the performance — and they are the piece most people skip, because they're awkward. Do them anyway. The minimum viable mock needs three things:

• A timer set to 35 minutes. That's a realistic coding slot once introductions and questions are trimmed off a 45-minute interview. The clock is the point: pressure changes how you think, and you want to have met that feeling before it counts.
• A problem you haven't seen, at your target difficulty — a random unseen Medium from a pattern you've studied. Chapter 23's roulette is a decent picker.
• Your voice. Narrate to the wall, to a rubber duck, to a friend, to a peer-mock platform — anything, as long as sound comes out. If a friend plays interviewer, hand them Chapter 1's four dials (problem solving, communication, code quality, verification) and have them score you.

Afterwards, grade the recording — and yes, record it; your phone is fine. You are listening for the two killers: silence longer than thirty seconds, and declaring done without testing. Both are pure habit, both are fixable in two mocks, and both cost more points than a suboptimal algorithm does.

On the day, you don't improvise; you run the loop you've run a hundred times: clarify → small example → brute force out loud → name the pattern → code the skeleton → trace & test. The only new variable is the budget. Thirty-five minutes divides roughly like this: a few minutes of clarifying and an example, about five of planning until you can say the pattern and its complexity, the bulk in code, and a protected block at the end for tracing your own solution — protected meaning: you stop coding to fund it.

The simulator below lets you mis-spend the budget in all the classic ways. Allocate the minutes and read the interviewer's notes: zero clarifying questions, no visible plan, no testing, or simply more minutes than exist — each has a price, and the prices are not equal.

You will get stuck. Interviewers expect it — several deliberately pick problems with a wall in the middle, because how you hit a wall is the most predictive thing they'll see all hour. Which means the stuck moment is not a failure state; it's a scored event you can rehearse. The rules:

• Never go silent. Silence is the only unrecoverable move. Thirty seconds of quiet reads as three minutes from the other chair, and it produces zero signal for anyone to defend you with later.
• Say what you know. Restating the constraints and what you've established is not filler — it's problem solving, out loud, and it frequently un-sticks you mid-sentence.
• Have moves, not hopes. Chapter 2's unstick moves — shrink n and do it by hand, try sorting, try a hash map, draw it — plus one more for the room: take the hint. A hint accepted gracefully and run with scores up, not down; it's coachability data, and coachability is on the scorecard.

Below are the five classic stuck states. For each, the widget shows the deadly-silence version and what the interviewer writes down — next to the graceful script and its move. Read the scripts out loud until they're yours; on the day they need to arrive without being fetched.

The twenty patterns are universal; the emphasis isn't. Treat the following as folk wisdom with a decent hit rate — teams vary, loops change yearly, and none of it replaces the map:

• Google leans toward graphs and DP — the Part IV and Part V material — and tends to care visibly about complexity analysis and clean generalization ("now suppose the graph doesn't fit in memory"). Budget extra reps on Chapters 15–17 and 20–21.
• Meta is famously about speed on Mediums: two problems in one slot is common, so the pattern must be recognized in seconds, not minutes. This is the loop's recognition drill paying rent — and why Chapter 23's roulette has a streak counter.
• Amazon is widely reported to braid Leadership Principles into everything; expect a lighter algorithmic bar but real behavioral weight in the same hour. Your narration habit does double duty here — the same out-loud clarity is what their behavioral rubric scores.
• Startups and smaller shops increasingly favor practical rounds (build a small thing, debug real code) — but when they do ask DSA, it's drawn from exactly this book's Easies and Mediums, hash maps and BFS ahead of anything exotic.

The strategic takeaway is boring and comforting: don't retrain for each company; re-weight. The map is the same; you're just choosing where to spend the review lap.

When your solution passes, the interview doesn't end; it promotes you a level. The follow-up is where senior signal lives, and it is nearly always one of four moves:

• Scale it: "What if the input doesn't fit in memory? What if it's a stream?" — they're fishing for heaps (ch. 14), or chunking, or the two-heap median trick.
• Constrain it: "Now do it in O(1) space." — the read/write pointer (ch. 5) or bit tricks (ch. 22) audition.
• Generalize it: Merge Two Sorted Lists Easy becomes Merge K Sorted Lists Hard — same problem, plus a heap of fronts. Two Sum Easy becomes "what if it's sorted?" (ch. 5) becomes 3Sum Medium.
• Break it: "What input would make this slow? When would you not use this structure?" — they want you to attack your own code, which is Chapter 1's verification dial at maximum.

Prepare for follow-ups the cheap way: after every practice problem, spend ninety seconds asking the four moves of your own solution. You'll walk into the room having already had most of the conversation.

Within an hour of your interview, the interviewer writes feedback they must defend in a debrief. It's specific and behavioral: "asked two clarifying questions that changed the approach", "named sliding window unprompted, stated O(n)", "went quiet for four minutes mid-solve", "tested on the empty string without prompting". Vague impressions don't survive a debrief; written-down moments do. Everything this chapter drills exists to put good sentences in that document — that's the whole game, stated plainly.

Close the loop on yourself the same way: after every mock and every real interview, write your own scorecard while it's fresh — what you'd cite for hire, what you'd cite against, logged by pattern, not by problem (Chapter 1's rule, one last time). Misses by pattern tell you what next week's review lap is for.

The last mile, as a whiteboard skeleton:

1. 1Book the date, count backward. Feed weeks × hours to the scheduler; if the verdict is red, change the inputs, not the ambition.
2. 2One pattern a day: 1 review + 2 new, every problem narrated out loud, pattern named before code.
3. 3One timed 35-minute mock per week from week two — unseen problem, recorded, graded on the four dials.
4. 4Taper the last two days: skim the 🎯 tells and section-8 skeletons, sleep. No new patterns after the taper line.
5. 5In the room, run the loop: clarify → example → brute force → name the pattern → code → trace & test. Budget the 35 minutes; protect the testing block.
6. 6Stuck = script, never silence: say what you know, shrink n, take hints audibly.
7. 7After "it works", invite the follow-up — scale, constrain, generalize, break — and run the loop again on it.
8. 8Debrief yourself in writing, misses filed by pattern; feed them to next week's review days.

For the finale, the classic "combine two structures" problem — LRU Cache Medium, the machine you watched run in Chapter 10's widget. It's the perfect last rep because it's pure pattern-composition: a hash map buys O(1) lookup, a doubly linked list buys O(1) reordering and eviction, and neither structure can do the job alone. Interviewers love it because designing the weld — nodes stored in the map, keys stored in the nodes — is where the thinking shows.

The comments below are not documentation; they're the narration you'd give while writing it — the sentences that turn a correct solution into a strong-hire performance. Read the code and the script together: that's the skill this whole book has been assembling.