Interview decision
Choose the smallest reasoning sequence that makes the requested behavior and evaluation artifact visible before naming classes.
Mental modelAn LLD answer is a revisable behavioral model: requirements create responsibilities; responsibilities create interfaces and state; a walkthrough tests the result.
Use it to
- Turn an ambiguous object-design prompt into one primary flow.
- Confirm whether the interviewer wants interfaces, pseudocode, code, or a diagram.
- Revise a boundary when a follow-up changes an assumption.
Keep out of scope
- Producing a complete production architecture.
- Demonstrating every design pattern you remember.
See the responsibility boundary
For a delivery workflow, schedule one delivery, change its status, and explain who owns each transition before adding carriers, routing, or notifications.
interface DeliveryWorkflow {
schedule(input: ScheduleDelivery): Result<Delivery, ScheduleError>;
transition(id: DeliveryId, next: DeliveryState): Result<Delivery, TransitionError>;
}Start from behavior, not a pattern
Low-Level Design is the design of responsibilities, interfaces, and state inside a bounded software component. Interviewers can observe whether you turn a use case into coherent behavior and defend the choices.
For a delivery workflow, start with “schedule a delivery and change its status,” then identify the objects that own scheduling and transitions. Do not start by announcing Factory or Observer.
Interviewer follow-ups
- Which use case should we optimize first?
- Is code expected, or are interfaces and a walkthrough enough?
Do not over-engineer: Do not model external databases, queues, or global traffic unless they change the object-level behavior being requested.
Use a repeatable, revisable flow
Clarify, model, assign ownership, define operations and state, walk a flow, then evolve the design. Move back when a new requirement exposes a bad boundary; iteration is evidence of judgment.
After a meeting room is booked, trace availability lookup, reservation creation, conflict validation, and confirmation. If cancellation appears later, revise the reservation lifecycle rather than layering a special-case helper.
Interviewer follow-ups
- What invariant should remain true after this operation?
- What is the smallest change for the follow-up?
Do not over-engineer: Do not turn every framework step into a separate diagram or ceremony. Use it to guide the conversation, not to delay a useful sketch.
Know the boundary
LLD concerns in-process collaboration, APIs, state, and test seams. System Design takes over when distributed storage, traffic, replication, availability, or network boundaries become the central design pressure. Low-level systems/C++ work takes over when memory, kernel behavior, cache coherence, or lock-free internals dominate.
A notification component can expose a Sender interface in LLD. Choosing a globally replicated delivery service with retry queues belongs in System Design.
Interviewer follow-ups
- Does this concern change an object contract or an architecture boundary?
- Should we defer this to the System Design curriculum?
Do not over-engineer: Do not invent a distributed subsystem merely to sound senior.
Validate the design, not the diagram
Walk one representative flow
- Clarify that scheduling and status transition are the primary behaviors.
- Create a Delivery in scheduled state through the workflow boundary.
- Ask Delivery to validate and apply a transition.
- Return a typed result and explain what stayed unchanged on failure.
Tests that protect the reasoning
- Scheduling with valid input returns a delivery in the agreed initial state.
- An illegal transition returns a domain error and leaves state unchanged.
- A new carrier requirement changes an adapter boundary, not Delivery lifecycle rules.
Evolve it without losing the boundary
- Follow-up change
- Add rescheduling after dispatch; identify whether the existing lifecycle owner can support it or whether a scheduling policy must be extracted.
- Concurrency, when relevant
- Discuss concurrency only if two commands can change the same delivery revision; name an atomic transition boundary instead of adding locks to every object.
- System Design boundary
- Queues, replicated tracking stores, routing fleets, and cross-region availability belong in System Design after the in-process contract is coherent.
What depth looks like by level
- Entry
- Complete one clear flow with sensible ownership.
- Mid
- Explain error contracts and one justified seam.
- Senior
- Control ambiguity, concurrency relevance, and follow-up evolution.
- Staff+
- Clarify organizational and system ownership without adding speculative classes.