Course Content
Object-Oriented Design Interview
14 sections · 29 lessons
The OOD round: what it is and where you will meet it
An object-oriented design interview is a 45-minute conversation in which you turn one sentence of English into a set of classes, the relationships between them, and working code for the two or three operations that carry the design.
What the prompt looks like
The prompt is deliberately short and deliberately vague:
"Design a parking lot."
That is the whole thing. There is no input format, no expected output, no test case. The first move is not to write code — it is to ask what kind of parking lot, because a single-level lot with one gate and a flat fee is a different design from a multi-floor lot with size-based spots, hourly pricing, and four entry gates.
What the whiteboard holds at minute 45
A candidate who did well leaves behind four things:
- A short list of requirements, written down, with the things you agreed to leave out.
- A class diagram: boxes with names and a few fields, lines with labels and multiplicities.
- Code for two or three methods — the ones where the design actually shows.
- A spoken answer to one extension question, like "now add electric-vehicle charging".
Nothing else. No persistence layer, no getters typed out, no user interface.
How it differs from the other two design rounds
| Algorithm round | OOD round | Distributed system design | |
|---|---|---|---|
| Deliverable | One function | Classes and relationships | Services, storage, protocols |
| Success metric | Correct and fast | Clean and extensible | Scales and survives failure |
| Typical unit | Big-O complexity | Responsibility per class | Requests per second |
| Concurrency | Rare | One machine, threads and locks | Many machines, replication |
| Length | 45 min | 45–60 min | 45–60 min |
The middle column is the whole course. The scale question here is "two cars reach the last free spot at the same instant", not "ten million cars a day across three regions". That is a smaller question, and it has a precise answer, which is why it gets asked.
Why it exists as a round
Companies run this round because it predicts the work. Most engineering days are not spent inventing algorithms. They are spent adding a feature to code someone else wrote, and the cost of that feature depends entirely on whether the existing classes were divided sensibly. This round is a 45-minute simulation of exactly that cost.
Where you will meet it
This round travels under at least four names, which is one reason candidates fail it: they prepare for something else, or they do not know it is coming.
The names
- OOD — object-oriented design. The name used in most published interview guides.
- LLD — low-level design. The dominant name in India, and the one you will see in job descriptions and recruiter emails there.
- Machine coding — a longer variant, described below, where you actually run the code.
- "Design a class for…" — how an interviewer often phrases it in the room, without naming the round at all.
If a recruiter tells you the loop has a "design round", ask which kind. The honest question is: "Is that a low-level design round where I produce classes, or a distributed system design round with services and data stores?" Recruiters answer this question happily, and the two rounds need different preparation.
Where it is standard
Based on candidate reports and published interview guides rather than any formal survey — treat this as a pattern, not a measurement:
- India. Low-level design is a standard round for mid-level backend and full-stack roles, and for many roles it replaces distributed system design entirely. Product companies and well-funded startups both run it.
- United States and Europe. Less consistently a separate round. It often appears folded into a coding round ("now make this extensible") or as an object-modelling discussion inside a system design interview.
- Games, embedded, and simulation roles worldwide. Common, because the domain is naturally full of stateful objects.
- Senior and staff loops. Less common as a standalone round, because the design conversation moves up a level of abstraction.
The machine-coding variant
Machine coding is the same problem with the clock loosened and the standard raised.
| Whiteboard OOD | Machine coding | |
|---|---|---|
| Duration | 45–60 minutes | Typically 90–180 minutes |
| Output | Diagram plus sketched code | A project that compiles and runs |
| Tools | Whiteboard or shared doc | Your own editor, no internet |
| Scored on | Reasoning out loud | Reasoning plus working code |
| Follow-up | Extension question, spoken | A code review with the interviewer |
Two practical differences matter. First, in machine coding you are expected to hand over something executable, usually with a small driver class or a few tests, so budget the last twenty minutes for making it run. Second, the code review afterwards is part of the score — you will be asked why a class exists, and "it felt right" is a losing answer.
Everything in this course applies to both. Machine coding adds a compiler; it does not change what a good model looks like.