Object-oriented design

What it is

Object-oriented design questions test whether you can turn a physical or game-like system — an elevator bank, a parking lot, a game board — into a small set of classes where each one owns a specific piece of state and exposes the operations that change it, with the relationships between classes (a lot has floors, a floor has spots, a spot holds a vehicle) mirroring the real relationships in the domain. The interviewer is watching for whether responsibilities land in the right place — should the "assign a spot" logic live on the lot, the floor, or a separate allocator — more than for any specific algorithm.

When it applies

• The prompt describes physical or simulated entities with clear containment or ownership relationships (a building has floors, floors have spots or cars, a board has cells).
• Multiple entity types interact through well-defined operations, and the design question is genuinely "what are the classes and how do they talk to each other," not just one class's internal algorithm.
• A single core allocation or interaction rule needs to be pluggable or extensible (how a spot is chosen, how score is tracked) — a sign the design should isolate that rule behind its own method or class rather than hardcoding it.
• An emphasis really on a state machine's transitions (this input in this state produces this output), rather than on which object owns which data, puts you closer to lld in general; and a system that needs to reason about scale, storage, or multiple servers at all is hld instead — object modeling alone doesn't cover throughput or persistence choices.

Tells in the problem

• "Show me the objects" or "design the classes for..." applied to a physical thing with parts (a building, a vehicle, a game board).
• Multiple distinct kinds of entity that must interact through defined operations, rather than one class with an internal algorithm.
• A stated allocation or matching rule ("a vehicle may use a spot of its own size or larger") that must be encapsulated so it can change later without touching unrelated classes.
• Explicit mention of concurrent callers acting on the same shared objects (several gates handing out spots at once), pushing the design toward safe, well-scoped mutation.
• A request to trace through a scenario step by step afterward, checking that the object graph actually produces the right answer.

The classic mistake

Putting one entity's logic directly inside another entity's class out of convenience — deciding which spot to assign inside the Vehicle class, or which floor to send a car to inside the Car class — because it's the first place that came to mind, rather than giving that responsibility its own object (an allocator, a scheduler) that both sides depend on, is the error that comes up most. This muddies the design the moment the rule needs to change (a different allocation policy, a different scheduling strategy), since now it's tangled inside a class that has nothing conceptually to do with the decision. Catch it by asking, for every method you add, "is this genuinely this object's own responsibility, or am I just putting it wherever was convenient" — a class that manages another class's decision usually belongs somewhere else.

Questions to start with

• Parking Lot — the cleanest containment hierarchy (lot, floor, spot, vehicle) and a single allocation rule to isolate correctly.
• Snake Game — a smaller object graph but a subtler correctness rule (the tail vacates its cell in the same step the head can enter it) that tests precise state modeling over class count.
• Elevator System — the most demanding one: several interacting entities (cars, floors, calls) plus a scheduling decision that has to be its own isolated piece of logic.