Use this checklist on every object-oriented design interview question. It is the same shape whether the prompt is a parking lot, an elevator system, or a rate limiter.

How OOD interviews differ from coding interviews

A coding interview grades whether your algorithm is correct and fast. An OOD interview grades something closer to judgment: can you turn a vague prompt into a set of classes that model the real system, stay easy to extend, and hold up when the interviewer adds a requirement mid-conversation. There is rarely a single correct answer - two candidates can both pass with different class layouts, as long as each decision maps back to a real requirement and the candidate can defend it. That is why interviewers weigh how you decompose the problem and communicate tradeoffs at least as heavily as the diagram you end up with.

Common OOD interview prompts

Most OOD prompts are one of a small number of "model a real-world system" shapes: a parking lot or garage, an elevator system, a vending machine, an ATM, a library or book-lending system, a ride-sharing dispatcher, a hotel or restaurant reservation system, a deck of cards for a game engine, or a rate limiter / cache with a swappable eviction policy. Different prompt, same seven steps below - start with Design a Parking Lot, a fully worked example, if you want to see the framework applied end to end before you hit one of these cold.

Step 1: Clarify requirements and scope

Ask what the system must do (core use cases) before naming a single class. Confirm scale (single machine or distributed?), who the users/actors are, and what is explicitly out of scope. Skipping this step is the most common way to design the wrong thing well.

Step 2: Identify the core entities (nouns)

List the real-world objects the system needs to model, the nouns in the problem statement. For a parking lot: Vehicle, ParkingSpot, Ticket, Level. Do not model everything; only what the use cases in Step 1 require.

Step 3: Identify the actions (verbs) and assign responsibilities

For each use case, ask which entity is responsible for each action. This is the single-responsibility check: each class should own one clear piece of behavior, not become a catch-all.

Step 4: Define relationships between classes

Decide composition vs. inheritance, and cardinality (one Level has many ParkingSpots; one ParkingSpot has at most one Vehicle at a time). Draw it, since a quick box-and-arrow diagram communicates more than a paragraph of description.

Step 5: Design for extensibility

State explicitly what should be easy to add later without rewriting the core: new vehicle types, new payment methods, new spot types. Favor interfaces and abstract base classes at the seams where variation is expected (a strategy pattern for payment, a factory for spot allocation), but do not over-engineer variation nobody asked for.

Step 6: Walk through the use cases against your design

Trace two or three concrete scenarios through your class diagram end to end (a car enters, finds a spot, pays, leaves). This surfaces missing methods and awkward relationships before the interviewer has to point them out.

Step 7: Handle follow-ups

Common follow-ups include concurrency (two threads claiming the same spot needs locking or an atomic reservation), persistence (where does state live if the process restarts?), and API design (what would the public interface of this class look like to a caller?).

The four principles interviewers expect you to know by name

You do not need a textbook definition, but you should be able to point at your own design and name which principle a decision serves. Encapsulation means each class hides its internal state behind methods, so a ParkingSpot decides for itself whether it is available rather than exposing a raw boolean anyone can flip. Abstraction means callers depend on what a class does, not how it does it, which is why a PaymentProcessor interface matters more than any single payment method underneath it. Inheritance models a genuine "is-a" relationship, a CompactSpot is a ParkingSpot, and gets misused constantly when candidates reach for it to share code between classes that are not actually related. Polymorphism lets you treat different spot types or vehicle types through one shared interface, so a Level can hand out spots without a chain of type checks.

Common OOD patterns worth knowing by name

Interviewers rarely ask you to name a pattern outright, but using the right one, and being able to say why, is what separates a design that just works from one that reads as intentional. A factory pattern fits anywhere you are creating one of several related object types (a spot factory that returns a CompactSpot, LargeSpot, or HandicapSpot based on input) without the caller needing to know the concrete class. A strategy pattern fits swappable behavior, most often payment methods or pricing rules, where the interface stays fixed but the implementation behind it changes. An observer pattern fits notification-style requirements, like alerting a display board when a level fills up, without the Level class needing to know who is listening. A singleton fits a genuinely single shared resource, like a central ParkingLot instance, though it is worth naming the tradeoff (harder to test, a hidden global dependency) rather than reaching for it by reflex.

Mistakes that cost candidates the round

The most common failure is not a wrong class diagram, it is skipping Step 1 and diving straight into class names before confirming what the system actually needs to do, which produces a technically fine design for the wrong problem. A close second is over-engineering: adding an interface, a factory, and a strategy pattern for a variation the interviewer never asked about, which reads as pattern-matching rather than judgment. The third is staying silent while drawing. Interviewers are grading how you think as much as what you produce, so narrate the tradeoff out loud when you choose composition over inheritance instead of just writing it down.

FAQ

What is OOD in software engineering?

OOD stands for object-oriented design: taking a real-world system and modeling it as a set of classes, each owning its own data and behavior, that interact through defined relationships. In an interview, it means turning a prompt like "design a parking lot" into class names, responsibilities, and relationships using the seven-step process above, not writing runnable code end to end.

What is the difference between an OOD interview and a system design interview?

A system design interview asks how a system scales across machines: load balancers, databases, caching, and message queues for something like a URL shortener or a news feed. An OOD interview asks how a system is modeled in a single process, or on a single machine: which classes exist, what they are responsible for, and how they relate. Some prompts blend both (a ride-sharing dispatcher can be asked either way), but the core skill being graded, distributed infrastructure versus class design, is different.

How many OOD questions should I practice?

Fewer than coding questions, but each one in more depth. Five to eight well-practiced prompts, spanning a physical system (parking lot, elevator), a transactional system (ATM, vending machine), and a service-style system (rate limiter, notification system), cover the shapes interviewers actually reuse. Redoing the same prompt with a stricter time limit teaches more than rushing through ten different ones.

Is OOD asked at every company?

No, it shows up most often at companies that build complex backend systems and want to see design judgment before a candidate reaches a system design round: think Amazon, Apple, and Oracle-style enterprise interview loops. Pure algorithm-heavy interview processes may skip it entirely, so confirm with your recruiter or check the company tags on the questions in this bank before you allocate practice time.

Related reading

• How to approach OOD interviews: the condensed version of this framework.