Design parking lot
The canonical warm-up. Easy to start, and almost everyone fumbles the same two questions.
warm-up · 45 minutes · 9 classes
Requirements
- Multiple floors, each with spots of several sizes — motorcycle, car, van.
- A vehicle arriving is allocated a spot it fits in, or rejected if none is free.
- Issue a ticket on entry recording spot and time; compute a fee on exit.
- Report free spots per floor, per size.
- Several entry and exit gates operating at once.
Say these are out of scope
- Payment processing — assume a fee is returned and someone else collects it.
- Reservations and season tickets.
- Number-plate recognition; assume the vehicle identifies itself.
A shape that works
One reasonable decomposition, not the only one. What matters in the round is that you can defend the boundaries you drew.
What they'll push on
Two cars arrive at different gates and the same spot is free. What stops both taking it?
Allocation has to be atomic — a lock over the spot, or a compare-and-set on its occupant that fails for the loser. This is the question the round is really about, and answering "I'd synchronise the method" without noticing that a lot-wide lock serialises every gate is the common miss. Lock per floor, or per size bucket within a floor, so gates only contend when they genuinely want the same spots.
Can a van take two car spots?
Only if you decide it can, and it changes the model: allocation stops being 'find one free spot' and becomes 'find N adjacent free spots', which needs spots to know their neighbours. Ask before designing. If the answer is yes, say the adjacency requirement out loud — it's the part interviewers are checking you spotted.
Where does pricing live?
Behind an interface, not in the lot. Hourly, daily cap, weekend rate and free-first-15-minutes are all the same shape, and they change far more often than the parking logic. This is Strategy earning its place rather than being applied for decoration.