OOD (also called LLD) is deciding which classes exist and which one owns each decision, then writing code that runs; the round scores whether those boundaries absorb the next requirement.
Core definitions
- Object: data bundled with the operations allowed on it.
- Class: the template; an object is one filled-in copy.
- OOD / LLD: same round; they differ only in how much code you type.
- Interface: a small named contract with no code behind it, fulfilled by several classes each their own way.
- Invariant: a statement that must hold before and after every operation (“one vehicle per spot”).
The one thing scored
- Measured: whether your object boundaries survive the next requirement.
- Good boundary = new requirement adds one class, edits nothing. Bad = edits six.
- Unit of cost: files touched per requirement change (not QPS, not GB).
- Move that makes change cheap: put an interface where change is expected. No second implementation in sight? Do not add the interface.
In and out
- In: one underspecified prompt (“design a parking lot”); your clarifying questions; one requirement change near the end.
- Out (all three): a class diagram; ~60-150 lines that actually run with asserts; a short account of the change in terms of files (new / untouched / cost).
Which round am I in?
| OOD / LLD | Classic system design | |
|---|---|---|
| Artifact | Class diagram + running code | Topology + data model |
| Decisive question | What changes next, who owns it | Read:write ratio |
| Unit of cost | Files edited per change | Storage, egress, fan-out |
| Scale | One process, one machine | A fleet |
Not asked here: capacity estimates, network topology, DB schema, LeetCode. If they say “now it’s 500 garages,” switch to system design.
The six prompt shapes
| Shape | The hard part |
|---|---|
| Resource allocation (parking, booking) | Matching, pricing, race for last unit |
| State machine (vending, elevator, ATM) | Illegal transitions, where the table lives |
| Rules engine (chess, blackjack) | Legality vs execution vs win detection |
| Hierarchy / traversal (file system) | Composite, recursion that spares the stack |
| Ledger (Splitwise, wallet) | Money as integers, atomic-or-absent |
| Feed of events (logger, notifier) | Observer, ordering, slow subscriber |
The two under concurrent access to money or a shared resource are where “add a lock” is not an answer.
The 45-minute shape
0-5 Clarify and scope
5-10 Actors and use cases
10-20 Objects and relationships (diagram + cardinalities)
20-25 The 2-3 decisions (pattern + change it makes cheap)
25-40 Code the core (make it run)
40-45 Extend~20 of 45 min are code + extension: no class typed by halftime, stop drawing. When short on time, cut drawing, never code.
Gotchas
- Naming a pattern scores one point; naming the change it makes cheap scores three.
- Concurrency answer is never “add a lock”: name which object owns it, its scope, and the failing interleaving.
- Reciting the four pillars or SOLID scores nothing on its own.
- Restraint is a strong answer: refuse at least one abstraction when nothing will vary.
- If an interpreter is open, run the code; interviewers read untested code as broken.