## 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. The software model leaves cameras, gate motors, and real payment processing outside its boundary. It focuses on the entities and responsibilities that make the lot work: where occupancy state lives and how the lot finds and reserves a fitting spot without assigning it twice. 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, we can separate objects that own state or behavior from values that only need an enum or parameter and concepts that do not belong in the model. 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 changing state that the design must protect, the spot is a class rather than a row in a 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. Rate policy is the one behavior the requirements explicitly expect to vary, so `PricingStrategy` becomes a swappable policy object. The prompt lists three vehicle types, so it is tempting to model `Car`, `Truck`, and `Motorcycle` as subclasses of `Vehicle`. But the only difference between a car and a truck here is which spot sizes each can use, and that is data rather than behavior. The comparison below shows why separate subclasses add no useful responsibility. :::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. This puts the variation where it belongs. Vehicle type is a closed set of data values, so an enum represents it directly, and the fit rule is one lookup rather than three overrides. Adding a van requires one enum value and one mapping entry, not a new subclass. ::: ::img[Entity relationship map]{src="https://assets.hack2hire.com/post/6a208e6f8b879849ebc11890/502dcb18-93a9-4159-9ff3-cbe910fb6ec9_20260603.svg"} After filtering, each remaining object has a clear responsibility. | 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 from the orchestrator. The first ownership decision is which object holds the authoritative fact that a spot is occupied. ### 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. The lot has to remember the full set of spots, find a fitting free spot on entry, look up an active ticket on exit, and apply a rate policy when it settles. Because rate policy is expected to vary, the lot holds it as a separate policy object. ```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? When a vehicle takes a spot, the design needs one authoritative place for the fact that the spot is occupied and a clear owner for changing 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. Each piece of state now has one owner and the common operations become cheap. Finding a fitting free spot pulls from the right size set, and `availability(size)` reads the set's size, both close to *O(1)*. The spot's guarded `occupy` prevents a double claim, while the index remains derivable from the authoritative flags. Entry becomes one guarded handoff: pull a free spot, occupy it, and remove it from the index. The find-and-occupy race is therefore confined to 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. The design now has two related state holders: the spot owns the occupancy truth, and the lot maintains a fast index of free spots. Every entry or exit keeps them aligned through a guarded handoff. A ticket then records the lifecycle of the parking event that uses that spot. ### 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 guard rejects a second `markPaid()` call at runtime: the method is legal only from `ISSUED`, so a repeated exit 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 stays in one place rather than being spread across vehicle subclasses. A motorcycle fits any size, a car fits compact or large, and a truck fits large only, all represented by one small mapping. ### Pricing as a policy The requirements expect flat, hourly, and tiered rates to change independently of the exit flow. Computing the fee inline in `exit` would make every rate-policy change edit that method. Keeping the computation behind a `PricingStrategy` lets the rate change without changing exit. ```js class PricingStrategy: + computeFee(entryTime: long, exitTime: long) -> Money ``` `PricingStrategy` is a swappable policy object that can be replaced without changing its caller. Pricing is the only baseline behavior explicitly expected to vary. Spot assignment can remain first-fit until another assignment policy becomes a real requirement. > [!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, `enter` and `exit` become short, guarded handoffs rather than scattered flag flips. `computeFee` adds the rounding rule used during exit. All three follow the same discipline: prove the operation can succeed before touching state. The main concurrent boundary is the find-and-occupy handoff shared by multiple gates. 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` combines the fit rule, free-spot index, occupancy handoff, and ticket creation. The no-fitting-spot case is handled before any mutation, so a rejected entry leaves the lot unchanged. - 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` reclaims state in an order that also rejects a ticket that was already settled. The flow is look up, validate, compute, release, and 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 ticket crosses its lifecycle boundary 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. Multiple gates can call `enter` at once, so the find-and-occupy handoff is a critical section. Guarding that handoff prevents two gates from claiming the same spot. Because occupancy and the availability index have clear owners, the critical section is limited to a few lines on the lot. ### A concrete example An end-to-end session shows how two pairs stay aligned: the spot's flag and index entry, and the ticket's status and 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 spot's flag and the index never disagree for longer than the guarded handoff, and the ticket crosses each lifecycle boundary once. These properties follow from putting occupancy on the spot and treating the lot's index as a cache rather than a second source of truth. ### Complete code implementation The complete Java and Python implementations use the same object model, state ownership, and method responsibilities. ::::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 Interviewers often use "what if" follow-ups to explore how a design changes. You usually explain where the change lands rather than fully implementing it. Because occupancy belongs to the spot, availability is a relational index, and pricing sits behind a policy, each extension below remains localized instead of rippling through entry and exit. ### Multi-level support Growing from one flat lot to many floors changes the container that owns spots and the free-spot index without rewriting the spot, ticket, or pricing. A `Level` owns its spots and per-size index, while the lot delegates search and availability across 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` remain unchanged because occupancy and the index already have clear owners. Moving the index into a `Level` is a relocation rather than a redesign. The new container addresses the structural need without changing the leaf objects. ### Pluggable pricing Supporting flat, hourly, tiered, or day-cap rates requires a new `PricingStrategy` implementation injected into the lot. `exit` and the rest of the lot remain unchanged because rate variation is contained behind the policy contract. ```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 ``` `enter`, `exit`, `ParkingSpot`, and `Ticket` remain unchanged because only the strategy object knows the rate policy. This is the *Strategy Pattern*, applied to the behavior the requirements explicitly expect to vary. ### 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 Supporting cash, card, and an app introduces a second independent policy. A `PaymentMethod` strategy handles collection at exit in parallel with the existing pricing policy. ```js // cash, card, app implementations class PaymentMethod: + collect(fee: Money) -> Payment ``` The fee computation and spot release remain unchanged because the new responsibility is how payment is collected, not what is owed or when the spot becomes free. `ParkingSpot`, `Ticket`, and `PricingStrategy` also remain unchanged. Pricing and payment vary independently, so each policy can change without editing the other or the surrounding 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.