Two hundred problems,
twenty patterns

Here's the uncomfortable fact: the interviewer usually knows the optimal solution before you sit down. If all they wanted was the answer, they'd read it off their sheet. What they're buying is signal — observable evidence, gathered in forty-five minutes, that predicts how you'd behave on the job. The answer is just the vehicle.

Concretely, they're watching three streams:

• Problem-solving out loud. Can you take a vague statement, pin down its constraints, try something, notice it's wrong, and repair it — while narrating? A silent correct answer scores worse than you'd hope, because silence produces no evidence.
• Code fluency. When the plan exists, does code fall out of your hands — or is every line a negotiation with the language? They're checking that syntax is not where your attention goes.
• Testing instinct. Do you trace your own code on an example before declaring victory? Do empty inputs, single elements, and duplicates occur to you unprompted? Engineers who verify are worth more than engineers who hope.

Notice what's not on the list: trivia, API memorization, whether you've seen this exact problem. Interviewers actively discount "they've clearly memorized this one" — recognition of the pattern reads as skill; recital of the problem reads as luck.

Most companies score some variant of four dials: problem solving, communication, code quality, and verification. Every behavior in the room nudges one or more of them. The toggles below are the behaviors interviewers actually write down — flip them and watch the dials respond. Note how cheap some of the biggest wins are: narrating costs nothing and moves two dials at once.

Why does the industry keep this ritual, given how artificial it is? Because it's the least-bad cheap filter anyone has found at scale: it's standardized (every candidate gets comparable problems), it's resistant to resume inflation, and — the part that matters for you — it's coachable. The dials respond to specific, practicable behaviors, not to genius. Chapter 2 turns those behaviors into a literal six-step script.

LeetCode hosts thousands of problems. That number terrifies people into grinding. But sort the bank by solution shape instead of by title and it collapses: a small number of reusable mechanisms — walk from both ends, slide a window, cache subproblems, search the answer space — cover almost everything. Call each mechanism a pattern: a recognizable problem shape plus a memorized code skeleton that solves it.

Don't take our word for it. Everyone who has tried to compress the bank lands on the same number from different directions:

• Blind 75 — a list of 75 problems posted on Blind by a Meta engineer, chosen as the minimal set that covers the recurring techniques. 75 problems, and nothing important missing.
• NeetCode 150 — the community-standard superset of Blind 75, organized into 18 categories. Same skeletons, more reps.
• Alex Xu & Shaun Gunawardane, Coding Interview Patterns (2024) — 19 pattern chapters, 101 problems, whole book.
• Grokking the Coding Interview — about 26 patterns, which on inspection are finer slices of the same set (it splits fast-slow pointers from in-place reversal, and so on).

18, 19, 26 — different knives, same cake. Round it to ~20 patterns. This book teaches them in Chapters 4–22, and the whole zoo is drawn below: two hundred problem dots, and the button that reveals the islands they were always sitting on.

Two candidates each solve 300 practice problems. One grinds them in random order, chasing the daily challenge. The other works pattern by pattern: learns the two-pointer skeleton, solves eight two-pointer problems, moves on. Interview-prep communities consistently report a gap like ~85% versus ~35% success between pattern-organized preparation and random grinding — and coaching services report that 60–80% of DSA questions at large tech companies are recognizable LeetCode-style variants.

Treat those numbers as what they are: reported community figures, not controlled studies. Nobody has run the randomized trial. But the direction is hard to argue with, because the mechanism is obvious: interview problems are novel instances of non-novel shapes. Random grinding trains your memory for instances, which you will never see again. Pattern study trains your eye for shapes, which you will see nothing but.

It's the difference between memorizing a phrasebook and learning the grammar. The phrasebook fails on the first sentence that isn't in it. The grammar generalizes — and generalization is literally the thing Section 1 said the interviewer is buying.

Patterns are not equal citizens. Hash-map problems are everywhere; trie problems are a rounding error. So coverage of the bank grows like a classic diminishing-returns curve: the first handful of patterns buys you half the bank, and each pattern after that buys a thinner slice. The curve below runs the real arithmetic against a 500-problem bank — drag the slider and watch where Blind 75 and NeetCode 150 chose to stand on it.

Read the endgame honestly: the curve tops out near 93%, not 100%. A few percent of problems are genuine oddballs — that's fine. The play is not perfection; it's making the common shapes automatic so your in-room thinking budget is spent on the disguise, not the mechanism. That's also why Blind 75 works at all: 75 problems is tiny, but it was chosen to touch every high-frequency pattern at least twice.

Here's how this book carves the territory. Part I (you are here) is the meta-game. Then:

• Part II · Linear Structures (ch. 4–10). Arrays, strings, and lists: hashing, two pointers, sliding window, prefix sums & intervals, stacks, binary search, linked lists. Seven patterns that solve roughly half the bank by themselves.
• Part III · Hierarchies (ch. 11–14). Trees, BSTs, tries, and heaps — where recursion stops being scary and starts being two reusable shapes.
• Part IV · Graphs & Exhaustive Search (ch. 15–18). BFS/DFS and flood fill, topological sort and union-find, Dijkstra, and backtracking — for when the structure is a web, or you must politely try everything.
• Part V · Optimization (ch. 19–22). Greedy when you can prove it, dynamic programming when you can't, plus the bit-twiddling and matrix party tricks.
• Part VI · Putting It Together (ch. 23–24). The whole book as one decision tree, then the practice schedule and day-of protocol.

Chapters cross-reference forward on purpose. When Chapter 6 says "the word subsequence sends you to Chapter 21", that's the map training your recognition reflex before you've even met DP.

Every pattern chapter runs the same three-beat loop, because the skill has three parts:

• Recognize. Learn the tells — the phrases and shapes in a problem statement that give the pattern away ("sorted array + pair with target", "longest substring such that…"). Each chapter marks these with 🎯 cards like the one above. Read them out loud; you're training a reflex, not storing a fact.
• Skeleton. Each chapter's section 8 ends with the pattern as a whiteboard skeleton — the 6–8 lines you'd actually write before filling in specifics. Memorize the skeleton, not the solutions; the solutions are the skeleton plus local color.
• Practice. A handful of canonical problems, by their real LeetCode names — Two Sum Easy, Group Anagrams Medium, Trapping Rain Water Hard — so the interviewer's problem is your third rep, not your first.

The widgets exist for the middle of the night before the interview: each one runs the real algorithm with counters exposed, so you can re-watch a mechanism in ten seconds instead of re-reading a chapter.

Two honest warnings before the checklist. First: reading is not practicing. A chapter feels understood the moment the prose makes sense, but recognition only becomes a reflex through reps — that's why every chapter ends with named problems and why Chapter 23 has a drill mode. Second: don't binge. One pattern that survives a week beats four patterns that evaporate by Friday; Chapter 24 builds the spaced schedule for you.

How to use this book, as a checklist:

1. 1Finish Part I first — the solve framework (ch. 2) and the complexity budget (ch. 3) are load-bearing for everything after.
2. 2One pattern chapter at a sitting. Play every widget until the stat counters stop surprising you.
3. 3Say each 🎯 tell out loud. Silly, effective. You're wiring statement-phrase → pattern-name.
4. 4Hand-copy the section-8 skeleton once — paper or whiteboard, not keyboard. That's the artifact you'll reproduce under pressure.
5. 5Solve 2–3 of the chapter's canonical problems within a day, cold, naming the pattern before writing code.
6. 6Flip every code card Python ⇄ Scala — seeing one idea wear two syntaxes is the cheapest generalization training there is.
7. 7Drill recognition weekly with Chapter 23's pattern roulette; log misses by pattern, not by problem.
8. 8Schedule the last mile with Chapter 24's practice-loop planner once an interview date exists.

Here's the book's whole method in one problem. Two Sum Easy: given an array and a target, return the indices of two numbers that sum to it. The brute force checks every pair — O(n²), "for each element, scan everything after it". The pattern replaces the inner scan with a question: have I already seen the number that would complete this pair? A hash map answers that in O(1), so the whole thing drops to O(n) — one pass. You trade memory for a time machine.

Read the delta between the two functions, not the functions: the loop survives, the inner loop becomes a map lookup. That delta — replace re-scanning with remembering — is the entire Chapter 4 pattern. Every pattern chapter's code card has this shape: brute force first (you'll say it in the room; it's your safety net), then the pattern as a small, memorizable edit.