Loading…
Low-level design interview questions test object modelling: class responsibilities, the relationships between them, and designs that absorb a new requirement without a rewrite.
Low-level design questions ask you to turn an informal description into types. Nothing leaves a single process, so there is no capacity arithmetic and no network to reason about; the entire assessment is whether the classes you produce have clear responsibilities, whether the rules that will change are separated from the ones that will not, and whether the model still holds when the interviewer adds a requirement in the last five minutes. The classic prompts — a parking lot, an elevator, a vending machine — are deliberately mundane, because the domain is not the point and any complexity in the answer has to come from the modelling rather than from the subject.
Interviewers watch for three habits. The first is asking what varies before drawing anything, since the parts described as changeable are the ones that belong behind an interface, and a candidate who models exactly the requirements as stated produces something that breaks on the first follow-up. The second is putting each rule in one place: the most common failure is a compatibility or pricing rule that appears in three classes, so that a change has to be made three times and will eventually be made twice. The third is knowing which behaviour does not belong to any single object — whether a chess move is legal depends on the whole position rather than on the piece, and a candidate who puts that check inside the piece has produced a design that cannot express the rules. Expect a follow-up that adds a feature specifically to see whether the answer extends or has to be rewritten.
6 low-level design · 1/3/2 easy/medium/hard
System design asks how a system spans machines — partitioning, replication, capacity, failure. Low-level design stays inside one process and asks how the code is organised: which classes exist, what each is responsible for, and which interfaces absorb the requirements that will change. A system design answer is judged on whether the design survives its own load; a low-level design answer is judged on whether it survives the next requirement.
Usually class skeletons rather than implementations — declarations, fields, and method signatures with the bodies sketched or omitted. The signatures carry the design: what is an interface, what is immutable, what a method returns when it cannot do the thing. Some companies run a longer machine-coding variant that does expect running code, which is worth confirming before the interview.
No, and the assumption catches out infrastructure candidates. The object-modelling prompts — parking lot, elevator, chess — are the best known, but the same round is run for SRE, DevOps and platform roles with a component or a workflow as the unit of design instead of a class: a deployment pipeline, a rollout and rollback controller, a secrets rotation workflow, a backup and restore strategy. There is no class diagram and usually no code; what is assessed is the same thing either way, which is whether the design has clear boundaries, puts each rule in one place, and survives a new requirement. TierOnePrep separates the two on the Operational Design topic page so neither audience has to read the other's questions.
Strategy and state account for most of it, because the common prompts all have one rule that varies (pricing, dispatch, splitting) and one object that behaves differently depending on where it is (a vending machine, an elevator). Command appears wherever undo is required, and factory wherever objects are created from input. Naming a pattern is worth far less than showing why that shape fits the requirement — an unprompted pattern applied to a problem that does not have the matching variability reads as worse, not better.