Approaching the OOD Interview

Scenario#

You will be given a prompt of the form “design an X” — a parking lot, an elevator, a library system, a chess game, a hotel, an ATM. The interviewer has 45 minutes. You have to leave the room with: a clarified scope, a class diagram, at least one narrated flow, and at least one defended trade-off. Anything less is a missed signal; anything more is unrealistic in the time.

This writeup is the meta-script — the rough minute-by-minute structure that produces those four artifacts under time pressure, plus the failure modes that eat the clock and how to avoid them.

Constraints#

The constraints are about the room, not the problem:

• 45 minutes, of which roughly 5 are introductions and the last 5 are the interviewer’s questions to you. You have ~35 working minutes.
• A shared editor or whiteboard — and the interviewer is reading what you draw in real time. The diagram is part of the communication, not just a reference for you.
• Two simultaneous audiences for everything you say — the interviewer (who wants to see decomposition skill) and a hypothetical reviewer of your code (who wants the class boundaries to make sense).
• Conversation, not monologue. The interviewer will interrupt with clarifying questions, push back on choices, and add follow-ups. Silence past about a minute reads as stuck.
• One language only — usually Java or whichever they hired you to write. The design talk is language-agnostic; the code sketch is not.

The prompts vary; the structure does not.

Approach#

The 45-minute round breaks into five phases. The minutes below are the median target — slip a little in either direction is fine; running off the end of the round without finishing the diagram is not.

Phase 1 — Clarify scope (5 minutes)#

The single most common LLD failure mode is starting to draw before clarifying scope. Resist it. Spend the first five minutes asking questions whose answers will narrow what you have to deliver.

A reusable checklist of clarifications, in order of value:

• Who are the users? A parking lot has a driver and an admin; a chess game has two players plus an observer; a library has a member, a librarian, and possibly a system. Naming the actors fixes the use case diagram before you draw it.
• What are the must-have features versus the nice-to-haves? Get an explicit list of three to five must-haves. Everything else goes on a stated out-of-scope list.
• What’s the scale? Number of items, peak rate, expected concurrency. The answer determines whether you sketch in-process structures or call out a persistence boundary.
• Are there constraints on platform, language, or external systems? “Pretend a payment gateway exists” is a useful answer; “design the payment gateway” is a different problem.
• What about edge cases the prompt didn’t mention? Lost ticket, dead battery, simultaneous arrivals, partial outage. Pick one and ask.

End the phase by reading the scope back. “So we’re designing X for actors A and B, with features F1/F2/F3, scale S, ignoring T1/T2 for now — is that right?” The interviewer’s confirmation is what gives you permission to commit to a direction.

Phase 2 — Identify entities and relationships (5 minutes)#

With scope in hand, list the nouns that the system traffics in. They are your candidate classes. Aim for somewhere between six and twelve — fewer means you have missed an abstraction, more means you have not decided what is a class versus a field.

For a parking lot, the nouns are: ParkingLot, Floor, ParkingSpot, Vehicle, Ticket, Payment, RateTable, EntryGate, ExitGate. For a chess game: Game, Board, Square, Piece (with subclasses), Move, Player, Clock.

Then name the relationships. Three kinds, in roughly decreasing frequency:

• HAS-A (composition / aggregation) — a ParkingLot HAS-A list of Floor. Default to this.
• IS-A (inheritance) — Car IS-A Vehicle. Only when the parent’s entire contract genuinely applies to the child.
• USES (transient dependency) — EntryGate USES ParkingLot to park a vehicle. Method parameters and short-lived references.

Two heuristics that prevent the most common entity-modeling mistakes:

• If you have two parallel hierarchies, look for a strategy pattern. “A Vehicle subclass for each fuel type and a Vehicle subclass for each size” is a 2D matrix of subclasses you do not want. Compose: Vehicle has a FuelKind and a Size.
• If you have a class with no behaviour, look harder. Pure data containers are usually a sign that the behaviour lives somewhere it should not. Move the behaviour next to the data.

Phase 3 — Draw the class diagram (10–12 minutes)#

Boxes for classes, with the names you settled on. Lines for relationships, with the right arrowhead — open diamond for aggregation, filled for composition, open triangle for inheritance. Multiplicities on the relationship ends (1, *, 0..1).

For each class, list two things:

• Two to four public methods. Not every method — the interesting ones. The ones that show the class’s role in the system.
• The state it owns. Two or three fields. Type plus name; visibility implied private unless otherwise drawn.

Things to draw and to not draw:

Draw	Skip
Class boundaries and their relationships	Every getter and setter
Method signatures that reveal collaboration shape	Constructor parameter lists
Inheritance only where IS-A holds	Marker interfaces with no methods
Patterns when they earn their keep (Strategy, State, Observer)	A pattern per class — pattern fatigue is a smell

The diagram is not for completeness; it is for legibility. The interviewer is mapping it to the flow you are about to narrate. If a box does not appear in the flow, it probably should not appear in the diagram.

Phase 4 — Narrate a flow (8–10 minutes)#

Pick the happy path for the most central use case — parking a vehicle, playing a move, borrowing a book — and walk through it as a sequence of object messages. “Driver calls parkVehicle on ParkingLot. ParkingLot asks each Floor in turn for a free spot. Floor walks its spots, calls fits(vehicle) on each, returns the first match. ParkingLot creates a Ticket, assigns the spot, returns the ticket to the driver.”

You do not need a formal sequence diagram on the board unless the interviewer asks for one. The narration is enough — and is the part of the round where most decomposition errors surface, because describing the message flow forces you to name who calls whom. If the narration produces a verb that does not have an obvious home, the class diagram is missing a class or has an SRP problem.

Then pick one unhappy path and walk through it briefly. Full lot. Lost ticket. Two cars at the same spot. Invalid move. The interviewer is watching for whether you can handle adverse paths without panicking.

Phase 5 — Defend trade-offs (5–8 minutes)#

The last working block is conversation. The interviewer will ask:

• “Why did you choose composition over inheritance for X?”
• “What happens when feature Y is added?”
• “How do you test this?”
• “Where would you put logging / observability / persistence?”
• “What changes if scale goes 10× / 100×?”

The questions are not gotchas. They are an audit of whether the choices in your diagram were choices, not defaults. Each answer should name the decision, the alternative, and the cost of the trade.

A template that works for most of these: “I picked X because Y. The alternative is Z, which is better when W happens — we’d refactor by doing V.” Three sentences. Move on.

Design decisions to make#

Most LLD prompts hide the same four decisions under different surface details. Pre-rehearsing them is the highest-leverage prep you can do.

Decision	Common right answer	The trap
Hierarchy or strategy for the varying behaviour?	Strategy in most cases — composition is the default.	Inheritance for what should be configuration; ends in a brittle tree.
Where does pricing / scoring / fee logic live?	A dedicated policy class (RateTable, ScoringRules).	Spread across the entity classes; impossible to change without redeploying half the system.
What is the state machine of the central artefact?	Explicit enum + guarded transitions on a single class.	Implicit, encoded across boolean fields; bugs at every off-diagonal.
Where does concurrency get serialised?	Coarse lock on the aggregate root, called out explicitly.	Locks scattered through leaves, with no global story.

If you can name your answer to each of these for the prompt you are given, you have already done 60% of the design work.

Trade-offs to discuss#

The five most common follow-up trade-offs and the shape of a defensible answer to each:

• Composition vs inheritance. “I went with composition because the variation is on N orthogonal axes; inheritance would require N×M subclasses or a deep tree. Inheritance would be right if there were a true IS-A relationship with shared behaviour we don’t want to duplicate.”
• Centralised policy vs distributed. “Pricing lives in RateTable so the team that owns rates can change them in one place. The cost is that RateTable knows about every vehicle type — acceptable because the list grows slowly.”
• Synchronous vs event-driven. “The exit flow is synchronous because the driver is waiting at the gate; analytics is event-driven via observers because it tolerates eventual consistency and we don’t want to slow the gate.”
• In-process state vs persistence. “I kept state in-process because the requirements said nothing about restart durability. If we needed it, I’d add a repository per aggregate (TicketRepository, SpotRepository); the interfaces are where the seam goes.”
• Coarse vs fine locking. “One lock on the lot is enough at our scale and is simpler to reason about. If contention shows up in load tests, partition by floor — that gives us 10× headroom without lock-free trickery.”

Evaluation criteria#

Interviewers usually rank candidates on five rough axes. The strong-and-weak signals are not symmetric — weak signals are weighted more.

Axis	Strong signal	Weak signal
Scoping	Asks five sharp questions in five minutes; reads the scope back.	Starts drawing immediately.
Decomposition	6–12 classes with clear responsibilities; SRP visible; one or two well-chosen patterns.	God class; pattern fatigue; class names that are verbs.
OOP fluency	Uses inheritance only for IS-A; composes the rest; can explain polymorphism in a sentence.	instanceof chains; deep hierarchies; setters everywhere.
Trade-off awareness	Names the alternative for every choice; gives the breakpoint at which the alternative wins.	Defends choices by repeating they are correct; no alternative offered.
Communication	Narrates as they draw; explicitly checks for understanding; finishes the round.	Long silences; abandons the original problem to chase a side issue; runs out of time.

A perfect round is rare. A passing round is consistent on scoping and decomposition, with at least passable signal on the other three.

Related exercises#

• Parking Lot — the canonical worked system. The exact run of this script applied to a single problem.
• Design a Ride-Sharing System — practice prompt; matching, surge pricing, driver-side workflow.
• Design a Food Delivery System — practice prompt; restaurants, orders, delivery agents, and the three-sided state machine.
• Elevator System — runner-up to Parking Lot in interview frequency; State pattern on the car itself.
• OOP Fundamentals — The Four Pillars — the vocabulary the interviewer assumes you have internalised before the round begins.