## 1. 🅿️ What is a parking lot system? A parking lot system manages a physical lot where vehicles enter, park in a spot that fits their size, and pay for the time they stayed. Drivers arrive at one of several gates, take a ticket, and the system points them to an open spot of the right size. When they leave, they hand back the ticket, the system works out the charge from how long they parked, takes payment, and marks the spot free again for the next car. In an object-oriented design interview, "design a parking lot" is not asking for cameras, gate motors, or a real payment processor. It is asking you to model the entities and responsibilities that make the lot work as software. The interesting questions are which nouns become real classes, where the occupancy state should live, and how the lot finds and reserves a fitting spot without ever handing the same spot to two cars. The lot supports three spot sizes (motorcycle, compact, and large) and three vehicle types (motorcycle, car, and truck), with smaller vehicles allowed to use larger spots but not the reverse. A ticket records the assigned spot and the entry time and acts as the token the driver returns on exit. Pricing is computed from parked duration so the design has a natural seam for swapping rate policies later. ## 2. Requirements Before modeling a single class, it is worth pinning down what the parking lot actually has to do and where the boundary sits. The core tension in this problem is not the feature list, it is making sure one spot is never handed to two vehicles at once, so most of the clarifying work is about lifecycle, ownership, and what counts as full. ### Clarifying Questions ::::qa-item :::you[You] "When a vehicle arrives, does the system pick an available spot for it, or does the driver choose their own spot?" ::: :::interviewer[Interviewer] "The system assigns a free spot that fits the vehicle and issues a ticket. The driver does not pick." ::: :::takeaway[Takeaway] Spot assignment is a responsibility of the orchestrator, not the driver, so we need a way to find a fitting free spot fast. That single decision is what later forces a free-spot index rather than a linear scan. ::: :::: ::::qa-item :::you[You] "What are the spot sizes and vehicle types, and can a small vehicle take a larger spot or only an exact match?" ::: :::interviewer[Interviewer] "Three spot sizes (motorcycle, compact, large) and three vehicle types (motorcycle, car, truck). A smaller vehicle may use a larger spot, but never the reverse." ::: :::takeaway[Takeaway] The fit rule is a one-to-many mapping from vehicle type to allowed spot sizes, not a one-to-one match. That keeps vehicle type as data rather than behavior, which rules out a `Vehicle` subclass per type, and it makes finding a spot a search over a set of sizes. ::: :::: ::::qa-item :::you[You] "Once a ticket is issued, can its entry time or assigned spot ever change before the vehicle leaves?" ::: :::interviewer[Interviewer] "No. The ticket is fixed at entry and is just the token the driver returns on exit." ::: :::takeaway[Takeaway] The `Ticket` is effectively immutable after creation, so entry time and spot reference are set once in the constructor. The only thing that moves is its lifecycle state, which means a small status field, not mutable data fields. ::: :::: ::::qa-item :::you[You] "How is the fee computed, and how do we round a partial hour, since that changes the settlement logic?" ::: :::interviewer[Interviewer] "Charge by parked duration at an hourly rate, and round any partial hour up to the next full hour for the baseline." ::: :::takeaway[Takeaway] Fee is a pure function of entry time, exit time, and a rate policy, so it belongs behind a swappable pricing seam rather than inline in exit. Round-up is a policy detail the seam owns, which keeps exit unchanged when tiered or day-cap pricing arrives later. ::: :::: ::::qa-item :::you[You] "Multiple gates can admit vehicles at the same moment. Do we need to guarantee that two concurrent entries never land on the same spot?" ::: :::interviewer[Interviewer] "Yes. Two vehicles must never be assigned the same spot, even if they enter through different gates at the same instant." ::: :::takeaway[Takeaway] This makes find-and-occupy a critical section that must be atomic. It is the strongest argument for keeping occupancy authoritative on one object and the lot's availability view as a derived index, so the guarded handoff stays small instead of spreading across scattered flags. ::: :::: ### Functional requirements - A vehicle enters through one of several gates and receives a ticket recording its assigned spot and entry time. - The system finds and assigns a free spot whose size fits the vehicle, following the fit rule (motorcycle fits any size, car fits compact or large, truck fits large only). - On exit, the driver presents the ticket, the system computes a fee from parked duration, collects payment, and frees the spot. - The system rejects entry when no fitting spot is available, distinguishing a full size class from a full lot. - The system reports current availability: free spots per size and whether the lot is full. - A spot is assigned to at most one active vehicle at a time, including under concurrent entries at multiple gates. ::::collapse[Out of scope]{variant="warning"} - Persistence, databases, or schema design (this is an in-memory object model). - Distributed coordination, sharding, multi-region, or horizontal scaling. - Reservations, monthly passes, memberships, or any user account or identity. - License-plate recognition, cameras, gate motors, sensors, or other hardware. - Real money movement or integration with an external payment processor. - Dynamic or surge pricing, demand forecasting, and analytics. - Spot-level wayfinding, electric-vehicle charging, and reserved or handicapped spot subtypes (named later as extensions). :::: ## 3. Choosing the Core Objects With scope settled, the first design move is to turn the prompt's nouns into the few objects that actually carry state and behavior. The question this section resolves is which candidates earn a class, which collapse into an enum or a parameter, and which we drop entirely. A few nouns jump out of the requirements: parking lot, parking spot, ticket, vehicle, vehicle type, spot size, gate, payment, pricing, and driver. Some of these are real entities with state and behavior. Some only look like entities on first read. Let us test them one by one before committing to a model. - `ParkingLot` is the obvious orchestrator. It owns entry and exit, holds the inventory of spots, and answers availability questions. Nothing else is positioned to coordinate the flow, so it stays. - `ParkingSpot` is the thing that actually gets occupied. It knows its own size and whether a vehicle is sitting in it. Because occupancy is real, changing state that the design has to protect, the spot earns a class rather than being a row in some table on the lot. - `Ticket` is the token the driver gets at entry and returns at exit. It records the assigned spot and the entry time, and it moves through a small lifecycle. That state plus identity makes it a class, not a receipt string. - `Vehicle` is the request that needs a fitting spot. It carries a `VehicleType` and, through the fit rule, the set of spot sizes it can use. It is thin, but it is the thing the lot reasons about at entry, so we keep it. That leaves the candidates that look like entities but are not. `VehicleType` (`MOTORCYCLE`, `CAR`, `TRUCK`) and `SpotSize` (`MOTORCYCLE`, `COMPACT`, `LARGE`) are closed sets with no behavior of their own, so they become enums. Gates hold no interesting state at the baseline, so a gate is at most an id parameter on `enter` and `exit`, not a class. `Driver` and `Customer` drop out entirely because there are no accounts in scope. Payment is a small value the exit returns, and the fee is a number the pricing policy computes, so neither needs a rich class. The one behavior the requirements explicitly expect to vary is the rate policy, so `PricingStrategy` survives as a seam, a swappable policy object, which we spell out in the next section. The most instructive rejection is the one most candidates reach for first. The prompt lists three vehicle types, so it is tempting to model `Car`, `Truck`, and `Motorcycle` as subclasses of `Vehicle`. But the only thing that differs between a car and a truck here is which spot sizes each can use, and that is data, not behavior. Listing types in the prompt does not mean each type needs a class, as the comparison below makes concrete. :::collapse[Bad Solution: A Vehicle subclass per type]{variant="bad"} This approach creates an abstract `Vehicle` base class and a concrete subclass for each type: `Car`, `Truck`, and `Motorcycle`. The intuition is that the prompt names three vehicle types, so three types should mean three classes, each knowing which spot sizes it fits. The problem is that the subclasses differ only in data, not behavior. None of them override a method or add one, so the hierarchy is pure ceremony. Worse, the fit rule ends up smeared across three classes, which means adding a fourth vehicle type later forces a new subclass even though nothing new actually behaves differently. The class count grows while the design gets no clearer, and a reader has to open three files to learn one mapping. ::: :::collapse[Good Solution: One Vehicle with a VehicleType enum and a fit rule]{variant="good" open} This approach keeps a single `Vehicle` class carrying a `VehicleType` enum value. The fit rule lives in one place, a small mapping from each vehicle type to the set of spot sizes it may use, so the rule is read and changed in exactly one spot. It wins because it puts the variation where the variation actually is. Vehicle type is a closed set of data values, so an enum models it honestly, and the fit rule is one lookup rather than three overrides. Adding a new vehicle type is one enum value and one mapping entry, no new class. This is the move that keeps the object model from exploding the moment the interviewer says "now add vans," and it reads as a deliberate decision rather than an accident of skipping inheritance. ::: ::img[Entity relationship map]{src="https://assets.hack2hire.com/post/6a208e6f8b879849ebc11890/502dcb18-93a9-4159-9ff3-cbe910fb6ec9_20260603.svg"} After that filtering, the cast is small and each member has a clear job. | Entity | Role | |--------|------| | `ParkingLot` | Orchestrator. Owns entry and exit, the spot inventory, the free-spot index, and availability queries. | | `ParkingSpot` | State owner. Holds authoritative occupancy and knows its own size. | | `Ticket` | Lifecycle token. Records the assigned spot and entry time, moves through issued, paid, closed. | | `Vehicle` | Request data holder. Carries a `VehicleType` and the fit rule for allowed sizes. | | `PricingStrategy` | Behavior seam. Computes the fee from duration, swappable without touching entry or exit. | | `VehicleType`, `SpotSize` | Enums. Closed sets of values with no behavior of their own. | ## 4. Shaping the Class Design With the four core objects settled, the next step is deciding what state each one owns and what methods it exposes. We work top-down, starting with the orchestrator so the responsibilities of the smaller objects fall out of what the lot needs from them. The single most consequential decision is who knows whether a spot is taken, so we start there before anything fancy. ### ParkingLot, the orchestrator `ParkingLot` is the object a caller talks to. It admits vehicles, settles exits, and answers how many spots are free. Everything else exists to serve those three jobs, so the lot's state is whatever it needs to coordinate them quickly. From the requirements, the lot has to remember the full set of spots, find a fitting free spot fast on every entry, look up an active ticket on exit, and apply a rate policy when it settles. That last one is the pricing seam the baseline already earns, so treat pricing as a policy object the lot holds. ```js class ParkingLot: - spots: List - availableSpotsBySize: Map> // free-spot index - activeTicketsById: Map - pricingStrategy + enter(vehicle: Vehicle) -> Ticket + exit(ticket: Ticket) -> Payment + availability(size: SpotSize) -> int + isFull() -> boolean ``` These fields belong here because they are system-managed relationships, not facts about any one spot. The `availableSpotsBySize` index and the `activeTicketsById` map are things the coordinator keeps about its parts. The harder question is what the lot should *not* own, and that is occupancy itself. ### Where does occupancy live? This is the central design decision for the whole problem, and most candidates start with the weakest version of it. When a vehicle takes a spot, where does the fact "this spot is taken" actually live, and who is allowed to change it? A tempting first move is to let the lot own everything: a boolean `isFull` and a `Map` on `ParkingLot`, with `enter` flipping entries in that map. It feels tidy because all the state is in one place. That tidiness collapses the moment you ask three questions the requirements actually demand: how many compact spots are free right now, which vehicle is in spot 14, and what happens when two gates flip the same entry at the same instant. When the spot itself knows nothing, every answer has to be reconstructed from the lot's bookkeeping, and concurrent entries can disagree about one spot. :::collapse[Bad Solution: A boolean and a vehicle-to-spot map on the lot]{variant="bad"} This approach keeps all occupancy on `ParkingLot`: a boolean `isFull` plus a `Map` that records who holds what. The `ParkingSpot` becomes a passive struct that knows only its size. Entry flips the map, exit removes from it, and availability is inferred from map size. It fails because the spot is anemic, so the truth about a spot lives somewhere other than the spot. Per-size availability needs a full scan of the map, "who holds spot 14" is a reverse lookup, and the boolean `isFull` is redundant state that can drift out of sync with the map. Worst of all, two concurrent entries both read the map, both see the spot as free, and both write it, double-assigning one spot. The state is centralized but unprotected, so correctness leaks everywhere a caller touches it. ::: :::collapse[Good Solution: An occupancy flag on the spot, linear scan to find one]{variant="warning"} This approach moves the truth onto the object it describes. Each `ParkingSpot` owns a free or occupied flag and the vehicle holding it, with `occupy` and `release` guarding the transition. To find a spot, the lot scans its full list and returns the first free one that fits. It improves correctness because the spot is now authoritative, so there is exactly one place that says whether a spot is taken, and a guarded `occupy` rejects a double claim. What still limits it is speed. Every entry is an *O(n)* scan over all spots, which is slowest exactly when the lot is nearly full and the scan walks almost everything before finding a spot. Answering per-size availability also means scanning, so the model is correct but does not give the fast availability the requirements ask for. ::: :::collapse[Great Solution: Intrinsic occupancy on the spot, relational free-spot index on the lot]{variant="good" open} This approach splits truth from lookup. Occupancy stays intrinsic to `ParkingSpot`, its own flag is authoritative. The lot keeps a relational `availableSpotsBySize` index, a per-size set of currently free spots, updated whenever a spot is occupied or released. The index is a cache over the spots' flags, never a second source of truth. It wins because each piece of state lives where it belongs and each operation becomes cheap. Finding a fitting free spot is a pull from the right size set, and `availability(size)` is the set's size, both close to *O(1)*. The spot's guarded `occupy` still prevents a double claim, so the index can be wrong only transiently and is always reconcilable from the authoritative flags. Entry becomes a single guarded handoff, pull a free spot, occupy it, drop it from the index, instead of a scattered set of booleans that any caller might flip. That is the decision that turns concurrency from a minefield into one small critical section. ::: > [!TIP] > In the interview I'd say: "Occupancy is intrinsic to the spot. The spot is the thing that gets occupied, so its own flag is the truth. The lot does not store who is parked where, it just keeps an index of which spots are free so it can find one fast. The index is a cache, the spot's flag is the source of truth." With occupancy settled, the spot's own shape is small and obvious. It owns its size and its occupancy, and it guards both transitions so no caller can occupy a taken spot or release a free one. ```js class ParkingSpot: - id: String - size: SpotSize - occupied: boolean - heldBy: Vehicle // null when free + occupy(v: Vehicle) -> void // Spot is free + release() -> void // Spot is occupied + fits(vehicle: Vehicle) -> boolean ``` The guards are the point. `occupy` and `release` are the only doors into occupancy state, and each checks its precondition before mutating, so an illegal transition throws instead of silently corrupting the spot. `fits` lives here too because whether a spot accepts a vehicle is a fact about the spot's size under the fit rule. Two senior ideas just stacked up, intrinsic occupancy and the relational index, so before adding a third concept it is worth one breath. The shape so far is: the spot knows the truth, the lot keeps a fast index of free spots, and every entry or exit keeps the two aligned through a guarded handoff. With that held in mind, the next object is the token that records a single parking event. ### Ticket, the lifecycle token `Ticket` represents one parking event from entry to exit. It records the assigned spot and the entry time, and it carries a small lifecycle that encodes what is and is not allowed to happen next. The requirements made the ticket effectively immutable in its data, so the spot reference and entry time are set once at construction and never change. What does change is status, and the legal moves are narrow. A ticket is issued at entry, paid at exit, then closed. You cannot pay a ticket twice, and you cannot free the spot before the exit is processed. ```js class Ticket: - id: String - spotId: String - vehicleType: VehicleType - entryTime: long - status: TicketStatus // ISSUED, PAID, CLOSED + markPaid() -> void // legal only from ISSUED + close() -> void // legal only from PAID ``` Entry time lives here, not on the spot or the vehicle, because it is intrinsic to the parking event the ticket represents, and the fee is computed from it at exit rather than stored mid-stay. The status field is what makes the double-pay bug impossible by construction: `markPaid` is legal only from `ISSUED`, so a second exit on the same ticket throws instead of charging twice. ::img[Ticket lifecycle]{src="https://assets.hack2hire.com/post/6a208e6f8b879849ebc11890/866e3519-aef9-439f-941a-0131da7b29e9_20260603.svg"} ### Vehicle and the enums `Vehicle` is the thinnest object in the design, and deliberately so. It carries a `VehicleType` and exposes the fit rule that maps its type to the spot sizes it can use. ```js class Vehicle: - type: VehicleType + fitsSize(size: SpotSize) -> boolean enum VehicleType: MOTORCYCLE, CAR, TRUCK enum SpotSize: MOTORCYCLE, COMPACT, LARGE ``` The fit rule is one place, here, rather than spread across vehicle subclasses, which is the payoff of the modeling choice from the previous section. A motorcycle fits any size, a car fits compact or large, a truck fits large only, and that whole policy is one small mapping. ### PricingStrategy, the one earned seam Pricing earns a seam even in the baseline, because there is already real pressure to vary the thing behind it. That pressure is explicit here: the requirements expect flat, hourly, and tiered rates to come and go. A tempting first move is to compute the fee inline in `exit`. That works until the lot owner wants tiered pricing next quarter, at which point every change to the rate policy edits the exit path. Keeping the computation behind a `PricingStrategy` means exit never changes when the rate does. ```js class PricingStrategy: + computeFee(entryTime: long, exitTime: long) -> Money ``` This is the only abstraction the baseline earns. It is a swappable policy object, a thing you replace without touching the code that calls it, and it stays a seam rather than a class hierarchy because there is exactly one axis of variation behind it. The spot-assignment policy could become a similar seam later, but at baseline first-fitting-spot is fine, so we name that as a future seam rather than building it now. > [!TIP] > In the interview I'd say: "I would keep pricing behind a small strategy seam even in the baseline, because rate policy is already the one axis the problem statement tells us may vary. That keeps `exit` stable while the pricing rule changes, without turning the whole design into a pattern catalog." ### Final class design Putting it together, here is the full set of classes, with occupancy intrinsic to the spot, a relational free-spot index on the lot, the ticket's lifecycle states, and the single pricing seam. ```js class ParkingLot: - spots: List - availableSpotsBySize: Map> - activeTicketsById: Map - pricingStrategy + enter(vehicle: Vehicle) -> Ticket + exit(ticket: Ticket) -> Payment + availability(size: SpotSize) -> int + isFull() -> boolean class ParkingSpot: - id: String - size: SpotSize - occupied: boolean - heldBy: Vehicle + occupy(v: Vehicle) -> void + release() -> void + fits(vehicle: Vehicle) -> boolean class Ticket: - id: String - spotId: String - vehicleType: VehicleType - entryTime: long - status: TicketStatus + markPaid() -> void + close() -> void class Vehicle: - type: VehicleType + fitsSize(size: SpotSize) -> boolean class PricingStrategy: + computeFee(entryTime: long, exitTime: long) -> Money enum VehicleType: MOTORCYCLE, CAR, TRUCK enum SpotSize: MOTORCYCLE, COMPACT, LARGE enum TicketStatus: ISSUED, PAID, CLOSED ``` The same model reads more clearly as a picture. The diagram below is a *UML (Unified Modeling Language)* class diagram, showing every class and enum with its fields, methods, and relationships in one view. ::img[Full UML class diagram]{src="https://assets.hack2hire.com/post/6a208e6f8b879849ebc11890/b0aeac45-eb51-42b7-884e-b388ab19fc61_20260603.svg"} ## 5. Key Flow Walkthroughs Now that occupancy lives on the spot and the lot keeps a free-spot index, the enter and exit methods become short, guarded handoffs rather than scattered flag flips. We walk three of them: `enter` and `exit` end to end because they are the two equally central flows, and `computeFee` because the rounding is a small but real algorithm. The one discipline the whole section follows is guard before mutate: prove the operation can succeed before touching any state. We keep concurrency to a one-line note here and defer the locking depth to the extensibility section, so it does not crowd out the lifecycle lesson. Before any of this, a practical note: check with your interviewer on what they want. Some want compiling code, some want pseudocode, and some just want you to talk through the logic at the whiteboard. We use language-neutral pseudocode here. ### Admitting a vehicle `enter` is the heart of the design, because it is where the fit rule, the free-spot index, the occupancy handoff, and ticket creation all meet. The thing worth getting right is ordering: the only failure case, no fitting spot, has to be handled before anything mutates, so a rejected entry leaves the lot exactly as it was. - reject when no fitting free spot exists for the vehicle's allowed sizes - otherwise pull a free spot, occupy it, and drop it from the index in one step - then mint the ticket and record it as active ```js enter(vehicle) spot = findAvailableSpot(vehicle) if spot == null throw error("No fitting spot for " + vehicle.type) spot.occupy(vehicle) availableSpotsBySize.get(spot.size).remove(spot) ticket = Ticket(generateId(), spot.id, vehicle.type, now()) activeTicketsById.put(ticket.id, ticket) return ticket ``` The non-obvious choice is that `spot.occupy(vehicle)` and the index removal happen together, right after the null check, and nothing before that line changes state. The spot's flag is the truth and the index is the cache, so the order is occupy the spot first, then update the index to match. If those two ever drift, the spot wins. ::img[Responsibility flow: enter]{src="https://assets.hack2hire.com/post/6a208e6f8b879849ebc11890/6d7877a2-d671-4054-98c2-9c893c8837b6_20260603.svg"} ### Settling an exit `exit` is the paired operation, and it is worth interview time because it has to reclaim state in the right order and reject a ticket that was already settled. The exit flow is look up, validate, compute, release, close. - reject an unknown or already-paid ticket before charging anything - compute the fee through the pricing seam from entry time to now - mark the ticket paid, then release the spot and return it to the index, then close the ticket ```js exit(ticket) active = activeTicketsById.get(ticket.id) if active == null throw error("Unknown ticket") if active.status != ISSUED throw error("Ticket already settled") fee = pricingStrategy.computeFee(active.entryTime, now()) payment = collect(fee) active.markPaid() spot = findSpotById(active.spotId) spot.release() availableSpotsBySize.get(spot.size).add(spot) active.close() activeTicketsById.remove(active.id) return payment ``` The ordering lesson is that the ticket crosses its lifecycle line exactly once. We mark it paid before releasing the spot, so a duplicate exit hits the `status != ISSUED` guard and is rejected before any spot is touched. Reversing those two would open a window where a second exit could free a spot that another vehicle already took. ::img[Responsibility flow: exit]{src="https://assets.hack2hire.com/post/6a208e6f8b879849ebc11890/cd431b65-f773-4911-8feb-39e6f0c32f51_20260603.svg"} ### Computing the fee `computeFee` is small but it is where the rounding policy lives, and it is the body the pricing seam exists to vary. The only subtlety is rounding a partial hour up so a 91-minute stay is charged as two hours. ```js computeFee(entryTime, exitTime) durationMillis = exitTime - entryTime hours = ceil(durationMillis / MILLIS_PER_HOUR) return Money(hours * hourlyRate) ``` Because this is the only place rounding is decided, swapping in tiered or day-cap pricing later is a new strategy with a different `computeFee`, and neither `enter` nor `exit` notices. A word on concurrency before the trace: multiple gates can call `enter` at once, so the find-and-occupy handoff is the critical section. At baseline we guard that handoff so two gates cannot claim the same spot. The clean part is that the state-ownership split already shrank the critical section to a few lines on the lot, and we work through the locking options in the next section. ### A concrete example It is worth running one session end to end, because this is where the intrinsic-occupancy-plus-relational-index split stops being theoretical. Watch two pairs stay aligned: the spot's flag and the index entry, and the ticket's status and its presence in the active map. - a car enters at gate 2. `findAvailableSpot` pulls a free compact spot, "C3", from `availableSpotsBySize[COMPACT]` - "C3"'s flag flips occupied first, then "C3" leaves the index. That order matters: the truth changes, the cache follows - a ticket "T-001" is created with "C3" and the entry time, and lands in `activeTicketsById`. `availability(COMPACT)` now reports one fewer - ninety minutes later the driver exits at gate 1. "T-001" is found and is still `ISSUED`, so the guard passes - `computeFee` rounds 90 minutes up to two hours. "T-001" is marked paid, "C3" is released and returns to the index, "T-001" is closed and removed from the active map The invariant the trace makes visible is that the spot's flag and the index never disagree for longer than the guarded handoff, and the ticket crosses each lifecycle boundary once. That is the direct payoff of putting occupancy on the spot and treating the lot's index as a cache rather than a second truth. ### Complete code implementation The full, compiling implementation in both Java and Python follows, with the same object model, state ownership, and method responsibilities taught above. ::::code :::java import java.util.*; enum VehicleType { MOTORCYCLE, CAR, TRUCK } // Declared smallest -> largest so best-fit allocation can scan in order. enum SpotSize { MOTORCYCLE, COMPACT, LARGE } enum TicketStatus { ISSUED, PAID, CLOSED } class Money { private final long amount; // Smallest currency unit Money(long amount) { this.amount = amount; } long getAmount() { return amount; } @Override public String toString() { return "$" + amount; } } class Payment { private final Money amount; Payment(Money amount) { this.amount = amount; } Money getAmount() { return amount; } } class Vehicle { private final VehicleType type; Vehicle(VehicleType type) { this.type = type; } VehicleType getType() { return type; } // A smaller vehicle may use a larger spot, not the reverse. boolean fitsSize(SpotSize size) { switch (type) { case MOTORCYCLE: return true; case CAR: return size == SpotSize.COMPACT || size == SpotSize.LARGE; case TRUCK: return size == SpotSize.LARGE; default: throw new IllegalStateException("Unknown vehicle type"); } } } class ParkingSpot { private final String id; private final SpotSize size; private boolean occupied; private Vehicle heldBy; // null when free ParkingSpot(String id, SpotSize size) { this.id = id; this.size = size; this.occupied = false; this.heldBy = null; } String getId() { return id; } SpotSize getSize() { return size; } boolean isOccupied() { return occupied; } Vehicle getHeldBy() { return heldBy; } boolean fits(Vehicle vehicle) { return vehicle.fitsSize(size); } // Authoritative occupancy lives here; precondition is that the spot is free. void occupy(Vehicle v) { if (occupied) throw new IllegalStateException("Spot " + id + " is already occupied"); occupied = true; heldBy = v; } void release() { if (!occupied) throw new IllegalStateException("Spot " + id + " is not occupied"); occupied = false; heldBy = null; } } class Ticket { private final String id; private final String spotId; private final VehicleType vehicleType; private final long entryTime; private TicketStatus status; Ticket(String id, String spotId, VehicleType vehicleType, long entryTime) { this.id = id; this.spotId = spotId; this.vehicleType = vehicleType; this.entryTime = entryTime; this.status = TicketStatus.ISSUED; } String getId() { return id; } String getSpotId() { return spotId; } VehicleType getVehicleType() { return vehicleType; } long getEntryTime() { return entryTime; } TicketStatus getStatus() { return status; } void markPaid() { if (status != TicketStatus.ISSUED) { throw new IllegalStateException("Ticket " + id + " is not in ISSUED state"); } status = TicketStatus.PAID; } void close() { if (status != TicketStatus.PAID) { throw new IllegalStateException("Ticket " + id + " is not in PAID state"); } status = TicketStatus.CLOSED; } } interface PricingStrategy { Money computeFee(long entryTime, long exitTime); } class HourlyPricingStrategy implements PricingStrategy { private static final long MILLIS_PER_HOUR = 3_600_000L; private final long hourlyRate; HourlyPricingStrategy(long hourlyRate) { this.hourlyRate = hourlyRate; } @Override public Money computeFee(long entryTime, long exitTime) { long durationMillis = exitTime - entryTime; long hours = (long) Math.ceil(durationMillis / (double) MILLIS_PER_HOUR); if (hours < 1) hours = 1; // any stay is charged at least one hour return new Money(hours * hourlyRate); } } class ParkingLot { private final List spots; private final Map> availableSpotsBySize; // free-spot index private final Map activeTicketsById; private final PricingStrategy pricingStrategy; private int ticketCounter; ParkingLot(List spots, PricingStrategy pricingStrategy) { this.spots = spots; this.pricingStrategy = pricingStrategy; this.activeTicketsById = new HashMap<>(); this.ticketCounter = 0; this.availableSpotsBySize = new EnumMap<>(SpotSize.class); for (SpotSize size : SpotSize.values()) { availableSpotsBySize.put(size, new HashSet<>()); } for (ParkingSpot spot : spots) { availableSpotsBySize.get(spot.getSize()).add(spot); } } // Prove a fitting free spot exists before touching state. synchronized Ticket enter(Vehicle vehicle) { ParkingSpot spot = findAvailableSpot(vehicle); if (spot == null) { throw new IllegalStateException("No fitting spot for " + vehicle.getType()); } spot.occupy(vehicle); availableSpotsBySize.get(spot.getSize()).remove(spot); String ticketId = "T-" + (++ticketCounter); Ticket ticket = new Ticket(ticketId, spot.getId(), vehicle.getType(), System.currentTimeMillis()); activeTicketsById.put(ticketId, ticket); return ticket; } synchronized Payment exit(Ticket ticket) { Ticket active = activeTicketsById.get(ticket.getId()); if (active == null) { throw new IllegalArgumentException("Unknown ticket: " + ticket.getId()); } if (active.getStatus() != TicketStatus.ISSUED) { throw new IllegalStateException("Ticket already settled: " + ticket.getId()); } Money fee = pricingStrategy.computeFee(active.getEntryTime(), System.currentTimeMillis()); Payment payment = new Payment(fee); // Mark paid before releasing the spot so the lifecycle crosses the line once. active.markPaid(); ParkingSpot spot = findSpotById(active.getSpotId()); spot.release(); availableSpotsBySize.get(spot.getSize()).add(spot); active.close(); activeTicketsById.remove(active.getId()); return payment; } // Scan allowed sizes smallest-first so a car does not waste a large spot. private ParkingSpot findAvailableSpot(Vehicle vehicle) { for (SpotSize size : SpotSize.values()) { if (!vehicle.fitsSize(size)) continue; Set free = availableSpotsBySize.get(size); if (free != null && !free.isEmpty()) { return free.iterator().next(); } } return null; } private ParkingSpot findSpotById(String spotId) { for (ParkingSpot spot : spots) { if (spot.getId().equals(spotId)) return spot; } throw new IllegalStateException("Spot not found: " + spotId); } synchronized int availability(SpotSize size) { return availableSpotsBySize.get(size).size(); } synchronized boolean isFull() { for (Set free : availableSpotsBySize.values()) { if (!free.isEmpty()) return false; } return true; } } ::: :::python from enum import Enum from typing import Dict, Set, List, Optional import math import time class VehicleType(Enum): MOTORCYCLE = "MOTORCYCLE" CAR = "CAR" TRUCK = "TRUCK" # Declared smallest -> largest so best-fit allocation can scan in order. class SpotSize(Enum): MOTORCYCLE = "MOTORCYCLE" COMPACT = "COMPACT" LARGE = "LARGE" class TicketStatus(Enum): ISSUED = "ISSUED" PAID = "PAID" CLOSED = "CLOSED" class Money: def __init__(self, amount: int): self.amount = amount def __repr__(self) -> str: return f"${self.amount}" class Payment: def __init__(self, amount: Money): self.amount = amount class Vehicle: def __init__(self, vehicle_type: VehicleType): self._type = vehicle_type @property def type(self) -> VehicleType: return self._type # A smaller vehicle may use a larger spot, not the reverse. def fits_size(self, size: SpotSize) -> bool: if self._type == VehicleType.MOTORCYCLE: return True if self._type == VehicleType.CAR: return size in (SpotSize.COMPACT, SpotSize.LARGE) if self._type == VehicleType.TRUCK: return size == SpotSize.LARGE raise RuntimeError("Unknown vehicle type") class ParkingSpot: def __init__(self, spot_id: str, size: SpotSize): self._id = spot_id self._size = size self._occupied = False self._held_by: Optional[Vehicle] = None @property def id(self) -> str: return self._id @property def size(self) -> SpotSize: return self._size @property def is_occupied(self) -> bool: return self._occupied @property def held_by(self) -> Optional[Vehicle]: return self._held_by def fits(self, vehicle: Vehicle) -> bool: return vehicle.fits_size(self._size) # Authoritative occupancy lives here; precondition is that the spot is free. def occupy(self, v: Vehicle) -> None: if self._occupied: raise RuntimeError(f"Spot {self._id} is already occupied") self._occupied = True self._held_by = v def release(self) -> None: if not self._occupied: raise RuntimeError(f"Spot {self._id} is not occupied") self._occupied = False self._held_by = None class Ticket: def __init__(self, ticket_id: str, spot_id: str, vehicle_type: VehicleType, entry_time: float): self._id = ticket_id self._spot_id = spot_id self._vehicle_type = vehicle_type self._entry_time = entry_time self._status = TicketStatus.ISSUED @property def id(self) -> str: return self._id @property def spot_id(self) -> str: return self._spot_id @property def vehicle_type(self) -> VehicleType: return self._vehicle_type @property def entry_time(self) -> float: return self._entry_time @property def status(self) -> TicketStatus: return self._status def mark_paid(self) -> None: if self._status != TicketStatus.ISSUED: raise RuntimeError(f"Ticket {self._id} is not in ISSUED state") self._status = TicketStatus.PAID def close(self) -> None: if self._status != TicketStatus.PAID: raise RuntimeError(f"Ticket {self._id} is not in PAID state") self._status = TicketStatus.CLOSED class PricingStrategy: def compute_fee(self, entry_time: float, exit_time: float) -> Money: raise NotImplementedError class HourlyPricingStrategy(PricingStrategy): SECONDS_PER_HOUR = 3600 def __init__(self, hourly_rate: int): self._hourly_rate = hourly_rate def compute_fee(self, entry_time: float, exit_time: float) -> Money: duration = exit_time - entry_time hours = max(1, math.ceil(duration / self.SECONDS_PER_HOUR)) return Money(hours * self._hourly_rate) class ParkingLot: def __init__(self, spots: List[ParkingSpot], pricing_strategy: PricingStrategy): self._spots = spots self._pricing_strategy = pricing_strategy self._active_tickets_by_id: Dict[str, Ticket] = {} self._ticket_counter = 0 # Free-spot index self._available_spots_by_size: Dict[SpotSize, Set[ParkingSpot]] = { size: set() for size in SpotSize } for spot in spots: self._available_spots_by_size[spot.size].add(spot) # Prove a fitting free spot exists before touching state. def enter(self, vehicle: Vehicle) -> Ticket: spot = self._find_available_spot(vehicle) if spot is None: raise RuntimeError(f"No fitting spot for {vehicle.type.value}") spot.occupy(vehicle) self._available_spots_by_size[spot.size].discard(spot) self._ticket_counter += 1 ticket_id = f"T-{self._ticket_counter}" ticket = Ticket(ticket_id, spot.id, vehicle.type, time.time()) self._active_tickets_by_id[ticket_id] = ticket return ticket def exit(self, ticket: Ticket) -> Payment: active = self._active_tickets_by_id.get(ticket.id) if active is None: raise ValueError(f"Unknown ticket: {ticket.id}") if active.status != TicketStatus.ISSUED: raise RuntimeError(f"Ticket already settled: {ticket.id}") fee = self._pricing_strategy.compute_fee(active.entry_time, time.time()) payment = Payment(fee) # Mark paid before releasing the spot so the lifecycle crosses the line once. active.mark_paid() spot = self._find_spot_by_id(active.spot_id) spot.release() self._available_spots_by_size[spot.size].add(spot) active.close() del self._active_tickets_by_id[active.id] return payment # Scan allowed sizes smallest-first so a car does not waste a large spot. def _find_available_spot(self, vehicle: Vehicle) -> Optional[ParkingSpot]: for size in SpotSize: if not vehicle.fits_size(size): continue free = self._available_spots_by_size.get(size) if free: return next(iter(free)) return None def _find_spot_by_id(self, spot_id: str) -> ParkingSpot: for spot in self._spots: if spot.id == spot_id: return spot raise RuntimeError(f"Spot not found: {spot_id}") def availability(self, size: SpotSize) -> int: return len(self._available_spots_by_size[size]) def is_full(self) -> bool: return all(len(free) == 0 for free in self._available_spots_by_size.values()) ::: :::: ## 6. Extensibility and Tradeoffs With enter and exit working, the real test is how the design holds up when the interviewer adds pressure. Because occupancy is owned by the spot, availability is a relational index, and pricing already sits behind a seam, each extension below tends to touch one place instead of rippling through entry and exit. That localization is the payoff of the earlier ownership decisions, and it is the thing worth pointing at out loud. Interviewers often ask these as "what if" follow-ups, and you usually explain where the change lands rather than fully implementing it. ### Multi-level support The boundary being tested here is structural: can the model grow from one flat lot to many floors without rewriting the spot, the ticket, or pricing. It can, because the only thing that changes is the container that owns spots and the free-spot index. We introduce a `Level` that owns its own spots and per-size index, and the lot delegates find and availability across its levels. ```js class Level: - spots: List - availableSpotsBySize: Map> + findAvailableSpot(vehicle: Vehicle) -> ParkingSpot + availability(size: SpotSize) -> int class ParkingLot: - levels: List // enter() now loops levels asking each to find a fitting spot ``` `ParkingSpot`, `Ticket`, `Vehicle`, and `PricingStrategy` are untouched, and that is not a coincidence to list mechanically, it is the point. Because occupancy and the index were already owned at the right level, moving the index down into a `Level` is a relocation, not a redesign. This is a composite-like container earned by a real structural need, not a pattern added for its own sake. ### Pluggable pricing This one tests whether the seam we placed at baseline actually pays off, and it does. Supporting flat, hourly, tiered, or day-cap rates is a new `PricingStrategy` implementation injected into the lot. The important thing to say here is that `exit` and the lot never change, because the variation point was put exactly where the requirements said the variation would be. ```js // [New] Swaps in for the baseline strategy class TieredPricing: // First hour is flat, additional hours use a lower tier, and daily cost is capped + computeFee(entryTime, exitTime) -> Money ``` Nothing else moves. `enter`, `exit`, `ParkingSpot`, and `Ticket` stay closed because the only thing that knows about rate policy is the strategy object. This is the *Strategy Pattern*, and it is genuinely earned here because rate policy is explicitly expected to vary, which is exactly the test for when a seam is worth its weight. ### Concurrent entries at multiple gates The boundary here is shared mutable state: several gates calling `enter` at once must never claim the same spot. The simplest correct fix comes first. Make the find-and-occupy handoff atomic by guarding `enter` and `exit` with a single method-level lock, so only one gate runs the critical section at a time. ```js // find-and-occupy now runs as one atomic critical section synchronized enter(vehicle) ``` If the interviewer pushes on throughput, that is when you escalate, not before. A single lock serializes every gate, so the next step is to shrink the critical section, for example a per-size lock so entries for different spot sizes do not block each other, or a compare-and-set on the free-spot set so the claim itself is atomic without a coarse lock. The reason the critical section is already small is the clean state-ownership split. Occupancy is guarded on the spot and the index is the only shared structure the lot mutates, so there is no scattered flag to also protect. No pattern is needed here, the design simply localized the race for us. ### Multiple payment methods This tests whether the design absorbs a second axis of variation as cleanly as it absorbed pricing. Supporting cash, card, and an app is a `PaymentMethod` strategy invoked at exit, parallel to how pricing already works. ```js // cash, card, app implementations class PaymentMethod: + collect(fee: Money) -> Payment ``` The fee computation and the spot release are unchanged, because the only new responsibility is how payment is collected, not what is owed or when the spot frees. `ParkingSpot`, `Ticket`, and `PricingStrategy` stay closed, and the exit fee and release logic is untouched. That the design absorbs a second strategy without disturbing the first is the real signal: the seams were placed at the genuine variation points, so each new policy plugs in rather than forcing edits to the flow. ## 7. Interviewer Expectations ### Junior A junior candidate gets the obvious cast on the board: `ParkingLot`, `ParkingSpot`, `Ticket`, and `Vehicle`, with `enter` and `exit` methods and a fit rule that decides which vehicle goes in which spot. They usually model occupancy as a flag and can describe the happy path of entering, parking, and paying. Where they tend to need a nudge is the failure case before mutation, often issuing a ticket and only then noticing there was no fitting spot, and they default to `Car`, `Truck`, and `Motorcycle` subclasses without questioning whether the subclasses do anything. If you can produce the four core classes, wire up a working enter and exit, and handle the lot-is-full case without double-assigning, you are in good shape for this level. ### Intermediate An intermediate candidate filters the nouns deliberately, keeping `VehicleType` and `SpotSize` as enums and folding gates into parameters, and they put occupancy on the spot rather than on the lot because the spot is the thing being occupied. They guard the no-fitting-spot case before any state changes, compute the fee from parked duration with sane rounding, and can talk about the ticket lifecycle as more than a string. They usually still need a hint to reach for a relational free-spot index instead of a linear scan, and they may name a pricing seam only after prompting rather than spotting the variation pressure themselves. The clearest signal at this level is putting occupancy on the spot, handling the edge case before mutating, and explaining why vehicle type is an enum and not a subclass hierarchy. ### Senior A senior candidate states the intrinsic-vs.-relational split out loud and unprompted: occupancy is authoritative on the spot, the lot's per-size free-spot index is a derived cache, and that single decision turns double-assignment from a scattered-flag bug into one guarded handoff. They place exactly one earned seam, pricing, and decline to abstract spot assignment until there is pressure to. They reason about concurrency by noting that the ownership split already shrank the critical section, starting with a simple lock before escalating, and they show that multi-level support touches one container class while the spot, ticket, and pricing stay closed. The clearest signal at this level is justifying the occupancy ownership decision in terms of correctness and change cost, and keeping the design flat under extension pressure instead of reaching for a pattern catalog.