Object-Oriented Design Interview

The object-oriented design round — "design a parking lot," "model a library system," "build a deck of cards" — tests something different from system design. No load balancers here. The question is whether you can turn an ambiguous real-world scenario into clean classes with sensible responsibilities, and evolve them as requirements shift.

What the interviewer is grading: not UML notation — judgment. Do your classes each own one job? Are relationships (has-a vs is-a) chosen correctly? Can the design absorb the inevitable "oh, also support electric-vehicle spots" without a rewrite?

A process that keeps you safe

1. Clarify use cases. "What operations must this support?" For a parking lot: park a vehicle, unpark, check availability, maybe pricing. Write them down — they become your methods.
2. Extract nouns and verbs. Nouns are candidate classes (Spot, Vehicle, Ticket, Level); verbs are candidate methods (park(), release(), isAvailable()).
3. Draw the relationships. A Lot has Levels; a Level has Spots; a Car is a Vehicle. Composition vs inheritance is the classic decision point.
4. Code the core path. Implement park() and unpark() for real; stub the rest.
5. Extend on request. The interviewer will mutate requirements. Show the design bends rather than breaks.

A compact sketch

class Vehicle {
  constructor(plate, size) { this.plate = plate; this.size = size; }
}

class ParkingSpot {
  constructor(size) { this.size = size; this.vehicle = null; }
  fits(vehicle) { return !this.vehicle && vehicle.size <= this.size; }
  park(vehicle) { this.vehicle = vehicle; }
  release()     { const v = this.vehicle; this.vehicle = null; return v; }
}

class ParkingLot {
  constructor(spots) { this.spots = spots; }
  park(vehicle) {
    const spot = this.spots.find(s => s.fits(vehicle));
    if (!spot) return null;            // lot is full for this size
    spot.park(vehicle);
    return new Ticket(vehicle.plate, spot);
  }
}

Then narrate the extension points: a strategy object for spot-selection (nearest-first vs best-fit), a pricer interface for hourly vs flat rates. You're showing where the design flexes before being asked.

Notice what the sketch deliberately leaves out: persistence, concurrency, payment rules. In a 45-minute round you build the skeleton in code and park the rest in words — "if two attendants grab the same last spot, we'd need a lock or a central allocator" — which proves you saw the hard part without spending twenty minutes inside it.

The principles that actually come up

You don't need to recite all of SOLID. Two earn their keep constantly: single responsibility (the spot-selection logic lives in a strategy, not smeared across ParkingLot) and open/closed (new vehicle types shouldn't require editing existing classes). Composition over inheritance is the third: a VIPSpot that has pricing rules beats a seven-level inheritance tree. If patterns come up, name the ones you'd genuinely use here — strategy, factory, singleton for the lot itself — and why, briefly.

Common mistakes

• Inheriting where you should compose. "Motorcycle extends Vehicle" is fine; "ParkingLot extends ArrayList" is an instant red flag.
• God classes. If ParkingLot also calculates prices, prints receipts, and sends emails, split it.
• Over-engineering with five design patterns in the first ten minutes. Start plain; introduce patterns as requirements justify them.
• Writing no code. A diagram alone doesn't prove the design works — implement the core path.

FAQ

How is this different from system design? System design is about distributed components and scale; OOD is about class-level structure in a single program. Some interviews do both — check the system design cheat sheet for the other half.

Should I draw UML? Boxes and arrows are enough. The interviewer wants the conversation, not diagram fidelity.

Practise OOD prompts live with Aissence mock interviews, and sharpen the delivery side with whiteboard interview tips.