Parking Lot — OOD Interview Walkthrough

Phase 1: Requirements & Use Cases

Interviewer: "Design a parking lot system."

Candidate: "Before I dive in, let me restate what I think we're building. A parking lot management system — something that handles vehicle entry and exit, assigns spots, tracks availability, and processes payments. Does that align with your expectations?"

Interviewer: "Yes. What actors are involved?"

Candidate: "I see three primary actors: a Vehicle (the entity parking), an Attendant or automated kiosk (managing entry/exit), and an Admin (configuring the lot). For use cases, I want to cover:

1. Vehicle entry — assign an appropriate spot and issue a ticket
2. Vehicle exit — calculate fee and process payment
3. Spot availability tracking — display real-time free counts
4. Support for multiple vehicle types (motorcycle, car, truck)
5. Support for multiple spot types (compact, large, handicapped, electric)
6. Admin operations — add floors, configure spot types"

Interviewer: "What about online reservations — booking a spot in advance?"

Candidate: "I'd scope that out of V1. It requires a temporal booking model, conflict resolution, and expiry logic that would double the design surface. The core OOD challenge — hierarchy, pattern application, payment — is fully covered without it."

WHY: Reservations introduce a booking state machine and time-window conflicts that distract from the class design being evaluated here.

Interviewer: "Do you need to handle concurrency — two cars entering simultaneously?"

Candidate: "Yes, I'll note it as a constraint. Spot assignment must be atomic — two concurrent entries should not get the same spot. I'll flag the synchronization point in the design but keep…