Low-level design

What it is

Low-level design questions hand you a single, self-contained system — an elevator bank, a parking lot, a vending machine, a text editor's undo stack — and ask you to produce the actual classes, their responsibilities, and enough of the method bodies to prove the design works, rather than a service architecture with network boundaries. There's no back-of-envelope math and usually no distributed system; the skill being tested is object modeling: which entity owns which state, how a state machine advances on each input, and how the design stays open to the follow-up the interviewer is already planning to ask.

When it applies

• The prompt describes a single machine, application, or object graph you could run inside one process, and asks you to "design the classes" or "show me the objects."
• Behavior naturally falls into distinct states (a vending machine has money in it or doesn't; a game is running or over) and the interesting logic is in the transitions.
• Concurrency shows up as "these calls can happen at the same time from different threads," not "these requests hit different data centers" — a much smaller-scale kind of concurrency than a distributed system's.
• A prompt that opens with a scale number (millions of users, requests per second) and expects a component diagram with load balancers and databases is hld instead — reach for that pattern's back-of-envelope approach rather than a class diagram.

Tells in the problem

• "Design the classes for..." or "show me the objects and how they interact," rather than "design the system that serves..."
• A concrete, physical, or single-process system named directly (an elevator, a parking lot, a vending machine, a game board) rather than an abstract service.
• A request to implement a specific method or two after the design, to prove the classes actually work together.
• Explicit state-machine language: "the machine should refuse and stay in this state," "after game over, further calls keep returning X."
• A same-process concurrency caveat — "several threads call this at once" — as opposed to multi-server or multi-region concerns.

The classic mistake

Jumping straight to a working set of classes for the happy path, and only discovering the real edge cases — the tail cell a growing snake can re-enter, the exact-change refund a vending machine must issue, the redo history that must be discarded after a fresh edit — when the interviewer asks about them, is the failure that comes up most often, rather than having the class design already accommodate them. This happens because a clean class diagram feels like "the design," when the actual interview signal is whether state transitions were thought through before code was written. Counter it by walking through every explicit edge case in the prompt's clarifying-questions section before finalizing a single class, and checking that each one maps to a specific state transition, not a special-cased if.

Questions to start with

• Parking Lot — a clean entity model (vehicles, spots, gates) with one clear allocation rule, a good first rep for object responsibilities.
• Vending Machine — a genuine state machine where each input (insert money, select, cancel) has a different valid response depending on the current state.
• In-Memory File System — a recursive tree structure where path parsing and directory creation drive the class shape.
• Elevator System — adds a scheduling decision on top of the state machine, plus thread-safe request intake while the simulation steps.
• Text Editor with Undo/Redo — the twist question: a history stack that must discard redo state on a fresh edit, testing whether the state model is precise, not just plausible.