Parking Lot

Step 1 · Clarify — 5 minutes, and it is the cheapest time you will spend

You cannot build “a parking lot”. You can build this parking lot. So shrink the problem until it has edges. Four or five short questions is enough — and you say the answers out loud so they become an agreement, not a guess.

• How big is it? — “Two floors, about 16 spots?” If they say “assume small”, a plain in-memory list is fine and you just saved yourself an hour of indexing.
• What can drive in? — “Bikes, cars, trucks?” Three types means three sizes, which means a spot has a size too.
• How is it charged? — “Per hour, paid at exit?” Now you know the ticket needs an entry timestamp. That one answer designs a whole class.
• What happens when it is full? — “Turn the vehicle away.” An answer here stops you from crashing on the demo.
• What is not in scope? — payments, login, a UI, a database. The most valuable question in the round is the one that removes work.

Step 2 · Nouns become classes, verbs become methods

Read your clarified problem back and underline the nouns. A noun that has its own data and its own behaviour is a class. Then underline the verbs — those are the methods, and they nearly always belong to the noun that owns the data they touch.

• ParkingLot — the front door of the system. It owns the floors and it is the only class the outside world talks to.
• ParkingFloor — a list of spots. In a small lot you can skip this and let the lot hold spots directly; say so out loud, and add it back the moment they mention multiple floors.
• ParkingSpot — has an id, a size, and either a vehicle in it or nothing. It knows two things: am I free? and does this vehicle fit?
• Vehicle — abstract, with Bike, Car, Truck under it. Each one answers what size spot do I need?
• Ticket — the contract between the lot and the driver: which vehicle, which spot, entry time. Once created, nothing on it changes except its status.
• SpotAllocationStrategy and PricingStrategy — the two rules that the interviewer is most likely to change on you. Interfaces, not if statements.

Step 3 · Write the API before you write the code

Before a single field, write the method signatures a caller would use. Names, parameters, return types — nothing else. If you can describe the whole system in four lines here, your model is right. If you cannot, you are still confused and it is far cheaper to find that out now.

lot.park(vehicle)              -> Ticket        // throws when the lot is full
lot.unpark(ticketId, exitAt)   -> Money         // the bill; frees the spot
lot.availableSpots(size)       -> int           // for the display board
lot.setPricing(strategy)       -> void          // swap the rule, not the code

Three things worth defending out loud, because interviewers ask about all three:

• park returns a Ticket, not a boolean. The caller needs something to bring back later. A boolean tells the driver nothing.
• unpark takes a ticket id, not the ticket object. A real gate scans a barcode. Taking an id also means the lot decides whether that ticket is still open — the caller cannot lie to it.
• Time is a parameter, not now() read inside. unpark(id, exitAt) is testable in one line. unpark(id) that calls the clock internally is not — you would have to sleep for an hour to test a two-hour bill. This is the single easiest senior-signal to give in this round.

Step 4 · The class diagram — draw it, do not describe it

Two small diagrams beat one crowded one. The first is the core model: what holds what. Read the diamonds as “owns” — a lot owns its floors, a floor owns its spots, and if the lot is demolished they go with it.

The second diagram is the part that wins the round. Both rules the interviewer is likely to change — which spot do we give out? and how much do we charge? — hang off the lot as interfaces, with the real rules as small classes underneath.

Step 5 · The two flows, message by message

There are only two stories in this system. Walk both out loud while you draw them — this is where an interviewer decides whether you actually understand your own diagram.

Choosing a spot: the rule everyone gets half-right

A bike fits in a bike spot. It also physically fits in a truck spot. So the naive rule — “find any free spot big enough” — is correct and quietly terrible: park three bikes and your two truck spots are gone. The rule you want is the smallest free spot that fits.

Once the size filter has run you still have a choice among equals, and that choice is the strategy. Two that are easy to defend:

• Nearest first — lowest floor, lowest spot number. Shortest walk for the driver. Floor 1 fills completely before Floor 2 gets a car.
• Spread out — send each arrival to the emptiest floor. Slower ramps stay clear, and no single floor jams at rush hour.
• Cheapest / reserved / EV-only — the same interface, more classes. This is why findSpot takes the spot list as a parameter instead of reaching inside the lot: the strategy stays a small, testable, stateless object.

Pricing: the same ticket, two different bills

The fee is a pure function of the ticket and the exit time. Nothing else. Keep it that way and pricing becomes trivially testable — and the interviewer's favourite follow-up becomes a one-liner.

• Round up to a started hour. 61 minutes is 2 hours. Say this out loud — it is the kind of detail that separates “I thought about it” from “I divided by 3600”.
• Charge a minimum. Somebody who leaves after 4 minutes still pays for one hour, or your lot is free for anyone doing a drop-off.
• Never bill from the current clock. Bill from ticket.entryAt to the exitAt you were handed. That is what makes the whole thing unit-testable.

The ticket has a life, and it can only move forwards

A ticket is issued, then paid, then closed. It never goes backwards. Modelling that as an explicit status — instead of inferring it from “is the spot empty?” — is what stops a ticket being billed twice.

Two cars, one spot — the bug nobody mentions until they do

A parking lot has several entry gates, and gates do not take turns. Two threads can read “F1-03 is free” in the same instant, and both can then write themselves into it. You just gave one spot to two cars, and the second one is going to be upset.

// ParkingSpot — the check and the take cannot be split apart
public synchronized boolean tryAssign(Vehicle v) {
    if (vehicle != null) return false;   // someone got here first
    vehicle = v;
    return true;
}

// ParkingLot — a loser just asks the strategy again
public Ticket park(Vehicle v) {
    for (int attempt = 0; attempt < MAX_RETRIES; attempt++) {
        ParkingSpot spot = allocation.findSpot(spots, v)
            .orElseThrow(() -> new LotFullException(v.getType()));
        if (spot.tryAssign(v)) return issueTicket(v, spot);
    }
    throw new LotFullException(v.getType());   // heavy contention, give up cleanly
}

The extensibility test — where they will actually push you

With ten minutes left, the interviewer stops asking about parking and starts asking about change. This is the real exam. Each of these should be answerable in one sentence, and the sentence should contain the words “a new class”.

• “Charge differently on weekends.” → class WeekendRate implements PricingStrategy. Wire it in main(). Nothing else is touched.
• “Fill the top floor first.” → class TopFloorFirst implements SpotAllocationStrategy. Same story.
• “Add electric-vehicle spots with a charger.” → a new SpotFeature (or an ELECTRIC spot type) plus an EvOnly strategy. One edit, because the size-fit rule now has a second dimension — say that honestly rather than pretending it is free.
• “Two entrance gates.” → no new classes; this is the concurrency answer above. tryAssign is already atomic, so you are done.
• “Show free spots on a board at the entrance.” → a DisplayBoard that the lot notifies on every park and unpark. That is Observer, and mentioning it by name costs you nothing.
• “Monthly pass holders skip the ticket.” → a ParkingPass and a second entry path. Be careful here: this is the one follow-up big enough to change your model, so scope it out loud before you touch anything.

Spending the 60 minutes

1. Enums and Vehicle first (3 min) — tiny, unblocks everything else.
2. ParkingSpot with fits and tryAssign (5 min) — the heart of the model.
3. ParkingLot.park() with a hardcoded nearest-first strategy (8 min) — get a ticket printing before you make anything pluggable.
4. Ticket + unpark() with the simplest pricing (8 min) — now the loop is closed and you have a working system.
5. Extract the two strategies (5 min) — only now. Extraction is a five-minute refactor when the thing works, and a rabbit hole when it does not.
6. main() demo (5 min) — park a bike, a car and a truck, print two bills, try to park into a full lot. Print it. Run it.

Five ways this round is usually lost

• Typing at minute zero. Twenty minutes later you discover the ticket needed an entry time and the rewrite eats the round.
• A god ParkingLot that finds spots, prices tickets, prints receipts and manages gates. Ask of each method: is this the lot's job? See Single Responsibility (SRP).
• Anaemic classes. ParkingSpot with nothing but getters and setters, while ParkingLot reaches in and mutates it. Behaviour belongs next to the data it touches — that is Tell, Don't Ask.
• Pattern cosplay. A ParkingLotFactoryProviderImpl before there is a single working park(). Two strategies is the right amount of pattern for this problem; see Pattern overuse & anti-patterns.
• No demo. If it does not run, most interviewers cannot give you the top band no matter how pretty the diagram was.

The follow-ups, and a one-sentence answer for each

You will be asked at least three of these. Rehearse the answers until they are boring — the calm, fast answer is the one that scores.

• “How do you handle 5,000 spots?” — Keep a free-list per (floor, size) instead of scanning every spot. Allocation drops from O(n) to O(1). Say it; only build it if there is time.
• “Multiple entry and exit gates?” — Gates are just callers of the same lot. The interesting part is concurrency, and tryAssign already handles it.
• “What if someone loses their ticket?” — TicketStatus.LOST plus a flat penalty rate. It is a new PricingStrategy, which is a nice thing to be able to say.
• “Reserve a spot in advance?” — Reservation is a third state on the spot (FREE / RESERVED / OCCUPIED) with an expiry. Warn them this changes the model — the spot is no longer a simple free/taken boolean.
• “Different rates per floor?” — The pricing strategy already receives the ticket, and the ticket knows its spot, which knows its floor. Zero model change.
• “Would you persist this?” — A ParkingLotRepository behind an interface, in-memory today, SQL tomorrow. See Repository — naming it takes four seconds and shows you know where the seam goes.

Where this design would genuinely stop working

• Many lots in many cities. The single in-memory ParkingLot becomes a service per lot with its own store. That is a high-level design conversation, not this round.
• Real money. Payments need idempotency, retries and a reconciliation trail. The moment payments are in scope, unpark returning a long is not enough.
• Sensors instead of gates. If occupancy comes from hardware events rather than park() calls, the lot becomes an event consumer and the ticket stops being the source of truth. Different problem; see Pub/Sub & Event-driven.