TL;DR: The object-oriented design interview (also called OOD or low-level design/LLD) hands you a fuzzy real-world thing, "design a parking lot," "design an elevator system," and grades how you turn it into clean, extensible classes. It is a different skill from the coding round (algorithms under time pressure) and the system design round (distributed systems at scale). The method that works: clarify requirements, extract the core objects, define relationships and behaviors, then refine with design patterns and SOLID principles, narrating tradeoffs as you go. The classic questions are finite and practicable, and Grokking the Object-Oriented Design Interview teaches them as 16 complete case studies.
Somewhere between the coding rounds and the system design round sits the interview nobody prepares for properly: you walk in expecting LeetCode, and the interviewer says "let's design a parking lot. No algorithms needed." Candidates who'd breeze through a graph problem suddenly have nothing to grab onto, because nobody ever taught them what this round is for.
I've run this round many times, and it's one of the most information-rich interviews we have. Here's what it tests, how it differs from the rounds you already know, and how to get good at it in a couple of weeks.
The three design-adjacent rounds, and which one this is
Companies test design at three different altitudes, and confusing them is the most common prep mistake:
| Coding round | OOD / LLD round | System design round | |
|---|---|---|---|
| Prompt sounds like | "Find the longest substring..." | "Design a parking lot" | "Design Instagram" |
| Altitude | One function or algorithm | One application's classes | Many machines, one system |
| You produce | Working code | Class design + key code | Architecture diagram + tradeoffs |
| Core skill | Pattern recognition, correctness | Abstraction and extensibility | Scale, storage, communication |
| Typical level | Everyone | Mid-level and up; big at Amazon | Senior and up |
The coding round asks can you solve it. The system design round asks can you scale it. The OOD round asks the question in between, and it's the one closest to the actual day job of most engineers: can you structure code that another human can extend next quarter without cursing your name?
Who gets it: Amazon uses LLD rounds heavily (often as a dedicated round in the loop; our Amazon guide covers where it sits in the pipeline), and it's common at Microsoft, at mid-size product companies, and effectively everywhere for backend roles. If you're interviewing beyond new-grad level, assume you'll meet it.
The 4-step method
Every good OOD answer I've seen followed roughly the same arc, whether the candidate knew they were following it or not. Practice it deliberately and the round becomes a procedure instead of a panic.
Step 1: Clarify requirements out loud (3-5 minutes). "Design a parking lot" is deliberately underspecified. Multiple floors? Different vehicle sizes? Payment? EV charging? You cannot design the classes before you've bounded the thing, and interviewers grade the questions you ask. Pick a scope, confirm it, write it down.
Step 2: Extract the core objects. The nouns in your requirements are candidate classes: ParkingLot, Floor, ParkingSpot, Vehicle, Ticket, Payment. The verbs are candidate methods: park, unpark, pay. Five to eight core classes is the right zone for a 45-minute round; twenty is a design smell.
Step 3: Define relationships and behaviors. Which classes own which (a lot has floors, a floor has spots)? Where does inheritance genuinely help (Car, Truck, Motorcycle extending Vehicle), and where is an enum or composition more honest? What's the lifecycle of the central operation, from a vehicle arriving to a ticket closing? Sketch the flow; write real code only for the one or two methods the interviewer cares about.
Step 4: Refine with patterns and principles, narrating tradeoffs. This is where good candidates separate: pricing becomes a Strategy so new rules don't touch old code; spot assignment becomes swappable (nearest-first now, priority zones later); notifications become an Observer. Name the extension you're enabling, not just the pattern: "I'm isolating pricing behind an interface so weekend rates don't require touching the ticket logic." That sentence is the round, compressed. The narration skill itself is trainable: see how to talk through a coding problem.
The classic questions
The OOD question pool is remarkably stable, which is what makes this round so practicable. The recurring cast:
- Parking lot: the canonical opener; ownership hierarchy plus a spot-assignment policy.
- Elevator system: state machines and scheduling; the hardest of the common set.
- Vending machine: states and transactions in miniature.
- Library management system: catalog vs physical copies, members, holds.
- Movie ticket booking: seat locking and the concurrency conversation it invites.
- ATM: transaction lifecycle, card/account separation, hardware abstraction.
- Chess (or tic-tac-toe): board, pieces, and move validation; inheritance done right or painfully.
- Hotel reservation system: rooms, rates, bookings, cancellations.
- Online shopping cart: items, pricing rules, checkout flow.
- Ride-sharing / food-delivery app (the LLD version): matching riders to drivers as objects, not as infrastructure.
Work through five or six of these deliberately and you'll notice the same seams recurring: a policy that wants to be swappable, a state machine hiding in a noun, an ownership tree, a resource being reserved. Those seams are the pattern layer of this round, the same way coding patterns are the recognition layer of the algorithm round.
Want them taught end to end? Grokking the Object-Oriented Design Interview works through 16 complete case studies (parking lot, movie ticket booking, ATM, chess, hotel management, Stack Overflow, and more), from requirements to class design to code in Java and Python, with object-oriented fundamentals and UML covered first for those newer to design.
What interviewers actually grade
Having sat on the grading side: it is not UML notation, and it is not naming every Gang of Four pattern. The rubric, in practice:
- Requirement discipline. Did you bound the problem before designing, and did your design actually serve the requirements you agreed to?
- Sensible abstractions. Classes that correspond to real concepts, responsibilities that live in one place, no god object running the show.
- Extensibility with a story. Not "I used Strategy" but "here's the change request this design absorbs without surgery."
- Judgment under change. Mid-round, I would change a requirement ("now add EV charging spots") specifically to watch whether the design bends or shatters, and whether the candidate revises calmly.
- Proportion. Knowing what to detail (the core flow) and what to wave at (getters, persistence). Candidates who perfect-code a
Ticketclass for twenty minutes lose the round to the clock.
The mistakes that sink candidates
Jumping straight to classes. Designing before scoping means designing the wrong thing confidently. The five minutes of questions are graded, not tolerated.
Pattern stuffing. Wedging six design patterns into a parking lot reads as memorization, not judgment. A pattern earns its place only when you can name the change it protects you from.
Inheritance everywhere. SmallSpot extends Spot extends Place extends Entity is how OOD answers drown. Reach for composition and enums first; inherit when behavior genuinely differs.
Silent designing. Two minutes of quiet sketching is fine; ten is a failed round, even with a good design at the end of it. The narration is the deliverable.
Ignoring the moving parts. Seat booking and spot assignment invite one sharp sentence about concurrency ("this reservation needs locking; here's the boundary"). Skipping it at mid-level and up is a missed layup.
How this fits your overall prep
The OOD round rewards a modest, targeted investment: for most candidates, two focused weeks alongside the main pipeline. The bulk of your prep time still belongs to the coding rounds (the patterns, a drill list, a schedule), because every loop has more coding rounds than design rounds. But going in with zero OOD reps when your loop includes an LLD round is how otherwise-strong candidates get a "no" that surprises everyone. Check your target company's loop shape (the Amazon, Google, and Meta guides say which rounds to expect), and slot the two weeks accordingly.
The takeaway
The OOD interview tests the skill you use most and practice least: turning a fuzzy requirement into classes that survive change. It's a different muscle from algorithms and from distributed systems, the question pool is small and stable, and the method (clarify, extract, relate, refine, narrating throughout) is completely learnable. Two deliberate weeks on the classics beats years of incidental OOP experience, because interviews grade the explicit version of what your day job does implicitly.
Prepare it properly: Grokking the Object-Oriented Design Interview teaches 16 classic questions as complete case studies for a one-time $65. Pair it with Grokking the Coding Interview for the algorithm rounds and you've covered the two rounds that decide most loops.
FAQs
Are OOD and LLD the same thing? Effectively yes. "Object-oriented design," "low-level design," and "machine coding" (in some markets) all refer to the same round: designing one application's classes and interactions. "High-level design" and "system design" refer to the distributed-systems round at the other altitude.
Which companies ask object-oriented design questions? Amazon most prominently (LLD is a standard part of many loops), Microsoft often, and a large share of mid-size product companies and backend-heavy teams. Google and Meta lean more on coding plus system design, but OOD thinking still surfaces inside their coding rounds when interviewers ask you to structure a solution as classes.
Do I need UML for the interview? No formal UML is required in most rounds; boxes, arrows, and readable code sketches are what they actually run on. That said, sketching a clean class diagram quickly is one of the clearest signals you can send, which is why the course spends a short chapter on exactly the diagrams interviewers recognize before its 16 case studies.
Which design patterns matter most for OOD interviews? A short list covers nearly everything the classics invite: Strategy (swappable policies like pricing), Factory (creating families of objects like spot or piece types), Observer (notifications and events), Singleton (used sparingly and with its downsides acknowledged), and State (elevators, vending machines). Knowing five patterns deeply, with the change each one protects against, beats naming twenty.
Is the Grokking OOD course beginner-friendly? Yes. It starts from object-oriented fundamentals (the four pillars, turning requirements into classes) and the UML you'll actually draw, before the 16 worked case studies with code in Java and Python. It's about 22 hours self-paced, a one-time $65, and basic programming is the only real prerequisite.
Do I need data structures and algorithms for this round? You need them in the background (a spot lookup might use a heap, and you should say so), but the round doesn't test algorithmic cleverness. If your fundamentals are shaky, fix that first with Grokking Data Structures & Algorithms; the OOD round assumes the vocabulary even though it grades a different skill.