Parking Lot

Problem framing

Design a multi-level parking lot: vehicles enter, get assigned a spot, pay on exit. Core skills tested: entity relationships, allocation logic, and Strategy for pricing.

Entity	Responsibility
ParkingLot	Facade: park(vehicle), unpark(ticket)
Level	Collection of spots on one floor
ParkingSpot	Size (compact/large), occupancy state
Vehicle / subclasses	Type determines eligible spot sizes
Ticket	Issued on entry: spot id, entry time
PricingStrategy	Calculate fee from duration + vehicle type

Allocation algorithm

Scan levels top-to-bottom (or nearest-first if specified). Within a level, find the smallest fitting spot — don't put a motorcycle in a truck spot if compact spots remain (interviewers notice waste). Encapsulate in SpotAllocator or a Strategy so ParkingLot stays thin.

Key flows

park() — validate lot not full → allocate spot → mark occupied → issue Ticket. unpark() — lookup ticket → compute fee via PricingStrategy → free spot → return payment amount. Handle edge cases verbally: lot full (reject or waitlist), invalid ticket, vehicle already inside.

Variants interviewers add

Multi-floor display boards, handicapped spots, valet service, or monthly passes — each maps to a new class or strategy without rewriting core allocation. Ask which variants are in scope before designing for them.

Senior-level signal

Separate spot type from vehicle type with a compatibility matrix rather than nested ifs. Mention extension: electric charging spots as a ParkingSpot subtype or a ChargingCapable interface — without building it unless asked. State assumptions: single entry gate, in-memory, no concurrency.

Where this goes next

Vending Machine shifts focus from allocation to state transitions — the classic State pattern problem with inventory and coin handling.