The parking lot is the most common OOD interview problem: and for good reason. It exercises every core skill: identifying entities from a real-world description, choosing the right class relationships, handling polymorphism with vehicle types, managing state transitions for spots, and applying patterns like Strategy for allocation and pricing. The system is simple enough to design in 30 minutes but rich enough to separate a beginner from a senior designer.

Before writing any code, define what the system must do. Start with actors and their interactions.

Actors: Drivers (park and retrieve vehicles), Attendants (manage entry/exit), System Admin (configure rates, levels).

Core use cases:

1. A vehicle arrives at the entrance and requests a parking spot
2. The system finds an available spot matching the vehicle's size and assigns it
3. The system generates a ticket recording the vehicle, spot, and entry time
4. The vehicle exits; the system calculates the fee based on duration and pricing rules
5. The spot is released and becomes available for the next vehicle

Vehicle types: Motorcycle (small, fits any spot), Car (medium, fits compact or large), Bus (large: needs multiple consecutive large spots).

Non-functional requirements: The system must handle concurrent entry and exit at multiple gates. Capacity information must be accurate in real-time. The pricing engine must support multiple strategies without code changes.

Why does this problem appear so often in interviews? Because the requirements are intuitive (everyone has parked a car), but the design decisions are non-trivial. How do you model the vehicle hierarchy? How do you find the right spot efficiently? How do you calculate fees without hardcoding pricing logic? Each decision reveals your design maturity.