Every problem in the room gets the same treatment: restate, small example, brute force priced, pattern named, skeleton coded, trace and test. When your mind blanks, the loop keeps moving — even while you aren't.
Chapter 1 showed what the interviewer is scoring: visible problem-solving, not a silent right answer. This chapter is the machine that produces that visibility on demand — a six-step loop you run on every problem, easy or hard, whether or not you recognize it. The loop is not a crutch for weak candidates; it's what strong candidates are doing when they look effortless.
The point of a fixed procedure is that it survives adrenaline. You will forget clever things in the room. You will not forget a loop you've run two hundred times in practice — and every step of it emits exactly the signal the four dials from Chapter 1 are listening for. Chapter 24 will put this same loop under a 35-minute clock; today we install it.
Here it is. Six steps, in order, no skipping:
Notice each step leaves behind an artifact — a clarified constraint, a worked example, a priced brute force — that later steps cash in. The walkthrough below runs all six on Valid Anagram Easy and shows you exactly what gets banked at each stop.
Step 1 has two halves. The restate half is for you: "So we're given two strings and we return true when they contain the same letters with the same counts — order ignored?" If you can't say it, you can't solve it; if you say it wrong, the interviewer corrects you now, for free, instead of twenty minutes into the wrong program.
The clarify half is an interrogation, and it's not politeness theater — the answers change the solution. Problem statements are deliberately underspecified, and hiding in the gaps are decisions about your data structures. Is the input sorted? (Sorted whispers two pointers, Chapter 5.) Can there be duplicates? How large is n? (That number sets your complexity budget — Chapter 3 is entirely about reading it.) And the classic:
Not all questions are equal, though. "Can values be negative?" usually changes nothing; "can I reuse an element?" changes the order of two lines and prevents a real bug. The drill below hands you an ambiguous Two Sum Easy statement and eight candidate questions — find the five that actually change the solution.
Step 2 is the one experienced engineers skip most, because it feels beneath them. It isn't. Working nums = [2, 7, 11, 15], target = 9 by hand does three jobs at once: it verifies your restatement against reality, it produces the test case you'll trace in step 6, and — this is the sneaky one — watching your own hands solve it often reveals the algorithm. When you catch yourself thinking "9 minus 2 is 7, have I seen a 7?", you've just discovered the hash-map solution out loud. Your hands knew the pattern before your head did.
Build the example adversarially. For Valid Anagram Easy, the pair "car" / "rac" confirms the happy path — but "aab" / "abb" is the one that earns its keep, because it kills the tempting-but-wrong "same set of letters" idea before it reaches your code. One vanilla case, one case designed to break your first guess.
Step 3 feels embarrassing and is actually a power move. Saying "the obvious approach is to check every pair — that's O(n²) — let me see if there's structure to beat it" accomplishes four things in one breath: it proves you can solve the problem (worst case, you code this and pass), it names a cost — instant credit on the problem-solving dial from Chapter 1 — it sets up the improvement story, and it buys you legal thinking time. Silence while you hunt for the clever answer reads as stuck; a priced brute force reads as methodical.
The price tag is mandatory. "I could brute-force it" is a shrug; "brute force is O(n²) — n is 10⁵, so that's 10¹⁰ operations, too slow" is analysis. It also tells you exactly how much better you need to be, which narrows the pattern search in step 4: needing to beat O(n²) on an unsorted array is practically a formal invitation to the hash map.
Step 4 is where this book's whole thesis reports for duty. You're not inventing an algorithm; you're running recognition. Interrogate what you've already banked:
For Valid Anagram, the restatement did all the work: "same letters with the same counts." Counting things is a frequency map — the bread and butter of Chapter 4. Say the name out loud: "this is a counting problem; I'll use a hash map, which makes it O(n) — one pass to count up, one to count down." Naming the pattern before coding it is among the strongest signals an interviewer can write down.
Step 5: write the pattern's memorized shape before any problem-specific cleverness. For a counting problem that's "guard on lengths, count up over one input, count down over the other, verdict" — four beats you can type without thinking, narrating each ("length guard first; that's the constraint we clarified"). The skeleton-first habit is why every pattern chapter in this book ends section 8 with a whiteboard skeleton: those 6–8 lines are the thing you reproduce here, under pressure, while your remaining attention handles the local details.
Step 6: your code is a claim, and claims get tested. Take the small example from step 2 and trace it through the code you actually wrote — not the code you meant to write — mumbling state as you go: "counts is {a:2, b:1}, now t's second b takes b to −1, return false. Correct." Then the edges you banked in step 1: empty strings, mismatched lengths, duplicates. Only then: "I'm confident in this — it's O(n) time, O(1) space for a fixed alphabet." That closing sentence is the verification dial's favorite food.
You will get stuck. The interviewer knows you will get stuck; some problems are chosen so that everyone does. Stuck is not the failure state — silent stuck is. The difference between candidates who recover and candidates who spiral is that the recoverers have a small menu of rehearsed moves, each of which re-enters the loop at a known step:
Pick your flavor of stuck below and get the move plus the literal line to say while making it.
Narration under pressure fails unless it's pre-written. These aren't suggestions of tone; they're lines to memorize verbatim, one per step, so your mouth has a default while your head works:
Say them out loud during practice — every rep of every problem, until the lines are muscle. In the room, the loop plus the scripts means there is no moment where you're deciding what kind of thing to say next. That decision was made weeks ago; Chapter 24 schedules the reps.
The pattern, as a whiteboard skeleton:
Here's the framework's output for Valid Anagram Easy, with the steps visible in the code itself. The brute force from step 3 — sort both, compare, O(n log n) ("sort once, then walk") — ships first, because it's the floor and it's honest. Then the step-4 insight: the restatement said counts, so a counting hash map does it in O(n) — count up over s, count down over t, and any dip below zero convicts. The length guard at the top is the step-1 clarification, cashed in as one line.
Read the comments as narration — they're roughly the sentences you'd be saying while typing. This counting map is your first real taste of Chapter 4, where it graduates from trick to pattern.