Why this matters: the middle act of an LLD round has a rule that surprises candidates every time it's enforced: you don't get to write code yet. The interviewer wants the design stated in words first — and if you dive for the keyboard, they will stop you. Understanding why they stop you tells you exactly what this act is grading.

Why words come first

Code is a terrible medium for evaluating structure in real time. By the time an interviewer can see your decomposition in code, you've spent fifteen minutes typing, the structure is expensive to change, and any correction they offer turns into a painful mid-interview refactor. Words are cheap: a design stated out loud can be probed, challenged, and revised in seconds.

So the act works like this: before implementing, you narrate the model. The interviewer probes it — "why does that class own pricing?", "what keeps those two indices consistent?" — and only when the design survives contact do you start writing. Candidates who code first aren't just breaking etiquette; they're hiding the very thing the round exists to grade, and interviewers read the hiding as inability to do it.

There's a second reason, less obvious: stating a design commits you to it. When you say "pricing lives in one place" and your code then smears it across three classes, the gap between the words and the code is itself signal. The words-first rule gives the interviewer a spec to hold your implementation against — one you wrote.

What a design statement contains

The content differs by flavor, but the shape is the same: the parts, what each part promises, and why the seams are where they are.

Machine coding: entities and responsibilities. Name the objects, give each one a single sentence of ownership, and describe the public surface — who calls what. The test of a good statement is that every future behavior has an obvious home. If the interviewer asks "where would discounts go?" and the answer takes you more than a beat, the responsibilities aren't really assigned.

Systems programming: layout and invariants. Name the memory shape — what lives where, what a slot or block or node looks like — and then the invariants: the properties that must hold before and after every operation. Then walk each operation as an algorithm in words. In this flavor the invariants are the design; code is just their enforcement.

What good sounds like

Two mini-examples — deliberately not from this course's problem set — to make the register concrete.

A machine-coding statement, for a vending machine:

"Three entities. Inventory owns what's in each slot and nothing else.
PaymentSession owns the inserted-coins lifecycle — accumulating, refunding,
committing — because payment rules will change independently of stock.
Machine is thin: it coordinates a purchase by asking Inventory if the slot
can vend and asking PaymentSession if the balance covers it. Pricing sits
with Inventory per-slot for now; if pricing ever gets rules of its own,
it's one extraction because nothing else reads prices directly."

A systems statement, for a fixed-size stack:

"A fixed array of N slots and one integer, top, counting occupied slots.
Two invariants: 0 <= top <= N always, and slots below top are the only
live data — I never clear popped slots, they're just dead by definition.
Push checks top < N, writes at top, then increments; pop decrements then
reads. Both O(1), no allocation after construction. The full/empty
questions are just top == N and top == 0 — no separate flags to drift."

Neither statement contains code, and both are complete enough to be graded: an interviewer can already probe the vending machine's seams ("where do multi-coin discounts go?") or press the stack's invariants ("what does a reader of a dead slot see?"). That's what "design in words" means — not vagueness, but structure without syntax.

The justification pattern: anticipate the change

Notice what did the persuasive work in the vending-machine statement: "because payment rules will change independently of stock." That is the justification pattern interviewers are listening for, and it has a fixed form:

"X is likely to change / varies independently, so I'm putting a seam there."

Structural choices justified this way convert opinion into engineering. "I'll make an interface for payment" is a preference; "payment rules change on a different schedule than inventory, so that seam earns its cost" is an argument — one the interviewer can test, and one that quietly prepares you for the round's fourth act, where something will change. Every seam you can defend this way is a place the twist can land harmlessly.

The inverse is also graded: seams you can't justify. An interface with one implementation and no change story is speculative generality, and a good interviewer will ask what it's for. "Just in case" is not an answer; flexibility has a cost, and knowing when not to pay it is the senior half of the skill.