Why this matters: the first points of an LLD round are won or lost before a single class exists. Most candidates treat the opening minutes as throat-clearing — a polite formality before the "real" work. Interviewers treat it as the first scored act, and they are taking notes the whole time.

The prompt is thin on purpose

"Design a parking lot." "Implement a memory allocator." That's the whole prompt, and the thinness is not laziness — it's the test. The interviewer is holding a sheet of requirement answers you cannot see, and the rule they play by is simple: they reveal one answer at a time, only when asked.

This inverts how most engineers expect an interview to work. Nobody is going to volunteer the constraints. The round opens with a silence that belongs to you, and what you do with it is the first thing being graded: do you notice the prompt is underspecified, and do you have a method for fixing that — or do you fill the silence with code?

A method: four lanes

Strong candidates don't ask random questions; they sweep the requirement space in lanes. Four cover almost everything, in either flavor:

Interface. What operations exist, exactly? What goes in, what comes out, who calls this? In machine coding this surfaces the use cases ("do users settle debts in the app, or do we just record them?"). In systems programming it surfaces the contract ("does free receive the size, or only the pointer?") — and, as we'll see below, contract questions have a habit of deciding your design for you.

Constraints and scale. How big, how many, how fast? A cache for a thousand entries and a cache for a hundred million entries are different problems. You don't need distributed-systems numbers here — you need the bounds that pick your data structures.

Failure semantics. What happens when it goes wrong? Out of memory, out of capacity, invalid input — is the answer an error, a null, an exception, undefined behavior? Interviewers love this lane because almost nobody visits it unprompted, and the answers are cheap points.

Out of scope. What am I explicitly not building? Getting a "no" is as valuable as a "yes" — every excluded feature is design surface you no longer owe anyone. Say the exclusion out loud so it's on the record.

You don't need all four exhaustively; you need each one opened, and the important answers pinned before the design starts.

The forcing requirement

Here is the phenomenon that separates good requirements-gatherers from question-reciters: some answers are not just information — they are design decisions in disguise. One of them quietly closes off an implementation path you were counting on, and the interviewer knows it.

The cleanest example in this course comes from the allocator domain. You ask about the interface and hear: "free takes only the pointer — no size." That single sentence forces the entire bookkeeping design. If the caller won't tell you how big the block was, the allocator must remember it — which means metadata stored per block, which means a header the pointer arithmetic must account for, which shapes everything you write for the next thirty minutes.

A candidate who hears that answer, nods, and moves on has collected a fact. A candidate who says "then the allocator has to track sizes itself — that means per-block metadata, so I'll plan for headers" has converted the fact into design, out loud, in the moment it arrived. Interviewers remember the second candidate.

What the interviewer is actually writing down

During this act, the notes on the other side of the table are not a transcript of your questions. They're closer to three checkboxes:

• Did questions come before design? Or did the candidate need to be dragged back from the code?
• Did the answers change anything? Questions whose answers are never used again are noise, and interviewers can tell.
• Did the candidate bound the problem? Scope explicitly narrowed, exclusions stated, a working set of constraints converged on — or is the problem still infinite when the design starts?

Notice what's not on the list: the sheer number of questions. Six questions that steer the design beat fifteen that don't.

The anti-patterns

Two failure modes account for most lost points in this act.

Jumping to code. The classic. The candidate hears the prompt, says "okay!", and starts typing a class. In a real round the interviewer will stop you — and that interruption is the grade. Everything you design before understanding the constraints is speculation with syntax.

The checklist recital. Subtler and more common among prepared candidates: firing off memorized questions — "What's the scale? What are the non-functional requirements? Any latency SLAs?" — writing nothing down, and then producing a design untouched by any of the answers. This reads worse than asking fewer questions, because it demonstrates the questions were performance, not inquiry. If you ask it, use it; if an answer changes nothing, you didn't need the question.