Design a Parking Lot: The #1 OOP Design Interview Question

If you are preparing for a design parking lot interview at Bloomberg, Microsoft, or Amazon, you are studying the right problem. This single question appears more frequently than any other OOP design prompt because it tests whether you think in objects, not just algorithms.

Unlike LeetCode-style problems where you optimize a function, OOP design questions ask you to model an entire system. The interviewer wants to see how you decompose a real-world domain into classes, define relationships, and apply principles like encapsulation and polymorphism.

The parking lot problem is deceptively simple on the surface — everyone knows what a parking garage looks like. But translating that intuition into a clean, extensible class hierarchy is where most candidates stumble. This guide walks you through every step, from requirements gathering to SOLID analysis.

Before writing a single class name, spend two minutes clarifying requirements with your interviewer. This is not wasted time — it is the most important signal you can send. Senior engineers always start by scoping the problem, and the design parking lot interview is no exception.

A well-scoped parking system design typically includes the following functional requirements: multiple floors, different vehicle sizes (motorcycle, car, truck), corresponding spot sizes (small, medium, large), entry and exit tracking via tickets, and optionally a payment system.

Non-functional requirements matter too. Ask about concurrency — can two cars enter simultaneously? Ask about scale — how many spots per floor? Ask about extensibility — should the design support adding new vehicle types like buses later? These questions demonstrate that you think beyond the happy path.

The heart of any parking lot OOP design is identifying the right entities. Start by listing nouns from the requirements: parking lot, floor, parking spot, vehicle, ticket, entry panel, exit panel. Each of these becomes a class or interface in your design.

Think of it as a hierarchy. A ParkingLot contains multiple Floors. Each Floor contains multiple ParkingSpots. Vehicles arrive at an EntryPanel, receive a Ticket, park in a ParkingSpot, and leave through an ExitPanel. This containment and flow model gives you the skeleton of your entire class diagram.

One common mistake is conflating entities. A ParkingSpot is not a Vehicle — a spot has a size and an occupancy status, while a vehicle has a size and a license plate. Keeping them separate ensures clean encapsulation and makes your parking lot class design easy to extend later.

The Vehicle class hierarchy is where you demonstrate your understanding of inheritance and polymorphism. Create an abstract Vehicle base class with shared properties like licensePlate and size. Then extend it with Motorcycle, Car, and Truck subclasses that set their own size enum value.

For ParkingSpot, use a similar approach. Each spot has a SpotSize enum (SMALL, MEDIUM, LARGE) and a method like canFitVehicle(vehicle) that checks whether the vehicle size is compatible. A motorcycle fits in any spot, a car fits in medium or large, and a truck requires a large spot. This size-matching logic is central to the design parking lot interview.

The ParkingLot class acts as the facade — it is the single entry point for all operations. It delegates spot finding to a SpotAssignmentStrategy interface, which can be implemented as NearestEntranceStrategy or LowestFloorFirstStrategy. This Strategy pattern is the design pattern interviewers most want to see in this problem.

Using a strategy interface means you can swap assignment algorithms without modifying ParkingLot. This is the Open/Closed Principle in action, and mentioning it explicitly will earn you points in any object oriented design parking interview.

Interviewers care less about the "right" answer and more about your reasoning. When they ask how you assign spots, explain the tradeoff: nearest entrance minimizes walk time but creates wear on lower floors, while distributing evenly extends floor life but increases walk time. Pick one, justify it, and mention the other as an alternative.

Handling a full lot is straightforward but often forgotten. Your ParkingLot should maintain a running count of available spots per size category. When a vehicle arrives and no compatible spot exists, the EntryPanel should reject the vehicle immediately rather than scanning every floor — this keeps the operation O(1) instead of O(n).

Thread safety is the advanced topic that separates senior candidates from junior ones. In a real parking system design, multiple cars enter simultaneously. Your assignSpot() method needs synchronization — either a mutex lock on the ParkingLot or optimistic concurrency with compare-and-swap on spot occupancy. Mention this even if you do not implement it fully.

Another key decision is whether a motorcycle can park in a large spot. The answer should be yes — this follows the Liskov Substitution Principle. Any vehicle that fits in a smaller spot should also fit in a larger one. Constraining motorcycles to only small spots would violate LSP and reduce lot utilization.

The parking lot SOLID analysis is what transforms a good answer into a great one. Walk through each principle and show the interviewer exactly where it appears in your design.

Single Responsibility Principle (SRP): Each class has one job. ParkingSpot manages occupancy. Floor manages its collection of spots. ParkingLot orchestrates the system. Ticket tracks time and fees. No class does two things, which makes every piece independently testable.

Open/Closed Principle (OCP): Your design is open for extension but closed for modification. Want to add a Bus vehicle type? Create a Bus subclass — no existing class changes. Want a new assignment strategy? Implement SpotAssignmentStrategy — ParkingLot never knows the difference.

Liskov Substitution Principle (LSP): All Vehicle subclasses are interchangeable through the Vehicle interface. Your canFitVehicle() method accepts any Vehicle and works correctly regardless of whether it is a Motorcycle, Car, or Truck. No special-casing, no type checks.

Dependency Inversion Principle (DIP): ParkingLot depends on the SpotAssignmentStrategy abstraction, not on a concrete strategy class. This means you can inject different strategies at construction time, making the system configurable and testable with mock strategies.

Start with entities, not code. Spend the first three minutes listing classes and drawing relationships on the whiteboard. The interviewer wants to see your object decomposition process before any implementation details.

Talk through tradeoffs explicitly. When you choose NearestEntranceStrategy, say "I chose this because it optimizes for user experience, but I could swap it for a load-balancing strategy if the requirement changes." This shows you think about extensibility, which is the core of object oriented design parking questions.

Mention what you are not building. Explicitly scoping out payment integration, real-time monitoring, or mobile app APIs shows maturity. You can say "I would add an Observer pattern for real-time dashboard updates as a follow-up" without implementing it.

Practice your parking lot class design with YeetCode flashcards to drill the entity list, SOLID mappings, and design pattern triggers until they are automatic. In a live interview, hesitation on basic class structure costs you the time you need for the interesting design discussions.

Remember that the design parking lot interview is not about a perfect solution — it is about demonstrating structured thinking, clean abstractions, and the ability to discuss tradeoffs. If you can articulate why your design is extensible and where it might break under new requirements, you have passed the test.