Interview decision
Ask only questions whose answers change behavior, ownership, state, or the expected artifact.
Mental modelRequirements are executable stories with actors, commands, queries, outcomes, and non-goals - not a feature wish list.
Use it to
- Bound parking entry and exit behavior.
- Separate elevator rider requests from maintenance behavior.
- Identify notification preference and delivery-result requirements.
Keep out of scope
- Enumerating every future feature.
- Treating quality attributes as generic words with no object-level consequence.
See the responsibility boundary
A vending purchase requires selection, sufficient payment, inventory availability, dispense, and change; remote fleet management remains outside the core.
interface VendingSession {
insert(money: Money): Balance;
select(slot: SlotId): Result<Purchase, PurchaseError>;
cancel(): Refund;
}Ask discriminating questions
Good clarification questions change ownership, state, or an interface. Ask about actors, the primary flow, cancellation or reversal, validation rules, and the expected design artifact.
Before designing a vending machine, ask whether it handles refunds, finite inventory, and multiple payment methods. Each answer changes state and responsibilities.
Interviewer follow-ups
- Which user flow is most important?
- What happens when the requested action cannot be completed?
Do not over-engineer: Do not attempt to enumerate every future feature before you have a first use case.
Turn a story into operations
A use case names an actor, a trigger, observable outcome, and important failure behavior. It gives the model a traceable reason for every public operation.
“A coordinator reserves a room for a time range and receives a conflict result when overlap exists” implies availability lookup, reservation validation, and a result contract.
Interviewer follow-ups
- What must be true before this operation?
- What result should the caller receive on conflict?
Do not over-engineer: Do not add CRUD operations for every entity unless a user flow needs them.
Use non-goals as a design tool
A non-goal is not a missing feature; it is an explicit boundary that lets the design stay defensible. Revisit it if a follow-up changes the exercise.
For a library checkout exercise, declare cross-branch transfers and fine payment processing out of scope while keeping a seam where policy could later change.
Interviewer follow-ups
- What would make this a System Design problem?
- Which extension is intentionally deferred?
Do not over-engineer: Do not build plugin systems for features the prompt never introduces.
Validate the design, not the diagram
Walk one representative flow
- Name the customer and one purchase goal.
- Confirm payment, inventory, cancellation, and change boundaries.
- Translate the story into commands and observable results.
- Record remote operations and settlement as non-goals.
Tests that protect the reasoning
- An unavailable item is rejected without changing balance or inventory.
- Cancellation returns the deposited amount.
- A card-payment follow-up changes the payment boundary without rewriting selection rules.
Evolve it without losing the boundary
- Follow-up change
- Add exact-change requirements and explain which command result and money policy change.
- Concurrency, when relevant
- Inventory races are relevant only if multiple sessions can reserve the same slot; otherwise keep the first model single-session and say so.
- System Design boundary
- Fleet telemetry, remote inventory synchronization, and payment networks are architecture concerns, not reasons to expand the object model prematurely.
What depth looks like by level
- Entry
- State actors, main commands, and non-goals.
- Mid
- Connect constraints to interfaces and failures.
- Senior
- Prioritize ambiguous requirements and expose hidden invariants.
- Staff+
- Set boundaries across product, component, and external-system ownership.