Parking Lot System Design
Scenario
“Parking lot” sounds like a toy until you treat it like a real system: dozens of entry lanes, multiple floors, policies (compact vs large, reserved, accessible, EV), and the one thing you cannot afford to get wrong—never sell the same spot twice. The interview is really about disciplined thinking: define rules precisely, model them cleanly, and then make concurrency and failure behavior explicit. Juniors learn that “classes” are not the goal; your goal is invariants. Seniors get pushed on how those invariants hold under retries, partial failures, and operational realities (devices offline, gates stuck open, humans overriding the system).
Parking lot is a great interview problem because it forces you to be precise. You have a finite resource (spots) and real-world rules (vehicle types, special spots, pricing). The system’s job is not to look “OO”; its job is to maintain a few hard invariants under concurrency.
Constraints
Vehicle entry/exit, spot allocation by vehicle type, availability by type, multi-floor, fee by duration, spot types (compact/regular/large)
Assign spot in < 1s, no double allocation, 1000+ spots, real-time availability
1000 spots, 5 floors; compact 400, regular 500, large 100; 2000 vehicles/day, ~3h avg, 80% peak occupancy; ~5 vehicles/min