How to approach OOD interviews

Object-oriented design interviews ("design a parking lot", "design an elevator system", "design a vending machine") don't have a single correct answer, and that trips people up more than the design itself. The prompt looks like a coding question. It is closer to a conversation the interviewer is grading for process - how you turn a vague paragraph into a model, not whether you land on the exact class diagram they have in their head.

The flow, in order

Skipping a step here is the most common way to lose points, because each step constrains the next one - designing entities before scope is fixed means redesigning them once scope lands anyway.

1. Clarify scope before you draw anything

The single biggest mistake is reaching for a class diagram in the first two minutes. Every one of these prompts is deliberately underspecified, and the interviewer wants to watch you notice that. "Design a parking lot" could mean a single flat lot with free spots, or a multi-level garage with reserved spots, EV charging, hourly billing and a mobile app. Those are different systems with different entities. Ask:

• What's in scope, what's explicitly out? ("Let's skip payment for now, focus on spot allocation" is a gift - take it.)
• What's the scale? One lot or a chain of lots. A handful of concurrent users or thousands. Scale sometimes changes the design, sometimes doesn't - but you won't know until you ask.
• Who are the actors? A driver, an attendant, an admin - each one usually maps to a use case you'll need to support later.

A minute of scoping questions here saves you from designing the wrong system carefully.

2. Identify the core entities

Once scope is fixed, pull the nouns out of the problem: ParkingLot, Level, Spot, Vehicle, Ticket. Not every noun in the prompt deserves a class - some are just fields on another entity - and the companion page on identifying entities and modeling relationships is the deeper technique for that specific judgment call. At this stage, say the entities out loud as you write them. The interviewer is listening for why something became a class, not just watching a list appear.

3. Identify relationships between them

A ParkingLot has Levels, a Level has Spots, a Spot may currently hold a Vehicle. Whether that's composition, aggregation, or a looser association is exactly the kind of distinction the class relationships page covers in depth - use that vocabulary here rather than reinventing it. Getting the relationship kind "wrong" rarely tanks an interview by itself; failing to reason about lifetime and ownership at all is what does.

4. Identify the actions - these become methods

Now the verbs: park a vehicle, remove a vehicle, find the nearest free spot, check the lot's capacity. Each verb becomes a method on whichever class owns the data it touches. This is also where you notice methods that don't obviously belong to any one entity yet - "find the nearest free spot" needs to search across levels, which is a sign ParkingLot (not Spot) should own it.

5. Sketch the class diagram

Only now, with scope, entities, relationships and methods already decided in conversation, does the diagram become a formality - you're writing down a decision you already made, not making it for the first time on the whiteboard. Keep it light: class names, key fields, key methods, arrows for the relationships from step 3. Nobody is grading your UML notation.

6. Walk through 2-3 use cases

Pick two or three concrete scenarios - a car parks and finds a spot, the lot is full and a car is turned away, a car leaves and its spot frees up - and trace them through the diagram by hand. This is where gaps surface: a missing method, a relationship that can't actually answer the question you're asking of it, an edge case nobody designed for. Fix what breaks as you find it, out loud.

7. Mention extensibility only where it earns its place

If the conversation naturally raises a future requirement - multiple pricing schemes, reserved spots for EVs - that's the moment to reach for a pattern (Strategy for the pricing variation, for instance), and the choosing design patterns page has the decision cues for exactly this. Don't force a pattern into a fifteen-minute design that has no variation to justify it - that's the fastest way to look like you're performing vocabulary instead of solving the problem.

Try it yourself: take "design a hotel room booking system" and run it through steps 1-4 out loud - what scope questions would you actually ask, which nouns become classes, which relationships connect them, and which verbs turn into methods - before you let yourself sketch a single box.

What's actually being graded

Interviewers who run these regularly aren't comparing your diagram against a reference answer, because there usually isn't one. They're watching for:

• Whether you ask before you assume. Silence and a confident wrong diagram loses to a clarifying question every time.
• Whether you can justify a decision when pushed. "Why is Spot an object instead of just a spot number?" should have an answer that isn't "I don't know, it felt right."
• Whether your model survives contact with a real scenario. A diagram that only exists to be admired, and was never traced through a use case, usually has a hole in it.
• Whether you know when to stop. Adding inheritance hierarchies, interfaces and patterns nobody asked for reads as over-engineering, not depth.

Getting to a working design that you can defend beats getting to the design you half-remember from a blog post. There usually isn't a canonical answer to defend against - only your own reasoning.

Check yourself

Question 1 of 3

You are five minutes into a "design a parking lot" prompt and already sketching a Vehicle class hierarchy. What did you skip?