Free lesson · Low Level Design Interviews
The Problem
The Problem - Parking Lot System
by Olena Marchenko - Software Engineer II, Microsoft Azure Developer Tools.
I want to start this case study with something most LLD content skips. The parking lot problem is treated as a warm-up. Easy. A junior question. "Just model some vehicles and spots." When I first encountered it in a Zalando mock interview years ago - early in my self-taught coding journey - I produced exactly the design that treatment encourages. A Vehicle class, a Spot class, a Lot class with a List of Spots, and a park() method that found an empty Spot and marked it taken. The interviewer politely said it "would work" and then asked me to extend it for electric vehicles with charging stations. I had no clean answer. I was rejected. Rejection number 4 of my eventual 11.
The parking lot problem isn't easy. It's deceptive. The surface is simple and lets weak candidates produce something that compiles and ostensibly works. The depth - vehicle polymorphism, spot compatibility, allocation strategy, pricing model, capacity tracking, multi-level navigation, concurrent access - is invisible until you start probing extensions. By then it's too late to fix the model. The interviewer has already concluded the candidate doesn't think about modeling rigor.
This case study takes the parking lot problem seriously. As a problem that, when designed cleanly, demonstrates OO modeling fluency at a depth most candidates never reach for. As a problem where the modeling decisions matter more than the implementation. As a problem that - when handled well - surfaces multiple design patterns (Strategy, Factory, State) in ways that are earned, not decorative.
This topic does the framing. What the problem actually requires. Why modeling is the centerpiece. Where the depth hides. How real systems vary. What the problem tests in interviews. Common misconceptions that derail candidates. And the roadmap into the six methodology steps.
What Is a Parking Lot System, Really?
A parking lot system manages a facility - usually a multi-level structure - that allocates parking spots to incoming vehicles, tracks their stay, calculates fees, and collects payment on exit. The user flow is intuitive: arrive at the entry gate, take a ticket, drive to an allocated spot, leave when you're done, present the ticket at exit, pay the fee, leave.
The engineering, again, is not. Let me decompose what the system actually does:
Vehicle entry. A vehicle approaches the entry gate. The system identifies the vehicle type (Car, Bike, Truck, Electric Vehicle, sometimes more specific subtypes). It checks whether the lot has any spot that can accommodate this vehicle type. If yes, it allocates a specific spot (according to some allocation strategy - nearest, first available, by-vehicle-preference). If no, it rejects the entry.
Ticket issuance. Assuming entry is allowed, the system issues a parking ticket. The ticket carries: a unique identifier, the entry timestamp, the vehicle's identifier (license plate or token), the allocated spot reference. The ticket is the user's proof of entry and the system's record of the active parking.
Spot occupation. The vehicle drives to the allocated spot. The system marks the spot as occupied. Real systems detect this via sensors (in modern smart parking) or trust the driver (in traditional lots).
Real-time capacity tracking. Across all spots in all levels, the system maintains a real-time count of available spots, often broken down by spot type. Display boards at the entry and on each level show the counts. Capacity tracking has to stay synchronized with allocations and releases.
Exit and fee calculation. When the vehicle leaves, the driver presents the ticket at the exit gate. The system looks up the ticket, calculates the fee based on the duration of stay and the vehicle type (and possibly the spot type). The fee is presented; the driver pays.
Payment. The system accepts payment via cash, card, mobile, or app. Successful payment unlocks the exit barrier. Failed payment keeps it closed pending resolution.
Spot release. Once the vehicle exits, the spot is marked available. Capacity counts update. The ticket is closed.
Special handling. Lost tickets get a different fee calculation (usually a flat penalty). Vehicles exiting without tickets trigger security flows. Reserved spots (for management, handicap permits, or pre-booked customers) bypass normal allocation.
That's the system. Eight concerns, each with its own complexity, all coordinated to make the user experience feel "just drive in and out."
The fundamental engineering challenge isn't building any of these in isolation. It's modeling them so that all eight cooperate without the model becoming a tangled mess of conditionals. The parking lot problem rewards modeling discipline like few other LLD problems do, because the temptations to over-couple or under-abstract are particularly strong here.
Why Modeling Sits at the Heart of This Problem
I want to make this point sharply because it's the framing that distinguishes the case study from generic parking-lot LLD content.
In the Movie Ticket Booking case study, the engineering challenges concentrated in concurrency and payment integration. In LRU Cache, they concentrated in data structure design. In parking lot, they concentrate in modeling. The hardest decisions are about what classes to have and how they relate - not about how to implement them.
Specifically:
Vehicle polymorphism. Vehicles vary by type, but how do you model that variation? Inheritance hierarchy (Vehicle → Car, Bike, Truck)? Enum-based with a vehicleType field? Composition with capability interfaces (SupportsCharging, OversizeFootprint)? Each choice has implications for how the rest of the system uses vehicles. The wrong choice forces awkward casts and instanceof checks throughout the codebase.
Spot compatibility. Different vehicle types fit different spot types. A bike fits in a compact spot; a truck doesn't. An EV requires a charging-capable spot if charging is requested. The model has to express compatibility - but where? On the spot (canAccommodate(vehicle))? On the vehicle (fitsIn(spot))? On a separate compatibility table? The location of this logic affects extensibility.
Allocation strategy. When a vehicle arrives, which spot gets allocated? The first available? The nearest to the entrance? The nearest to the exit? The one closest to amenities (like elevators or restrooms in a mall)? The cheapest? Different lots want different strategies. The model has to support pluggable allocation logic without baking one specific strategy into the core.
Pricing model. Fees vary by duration, vehicle type, spot type, and sometimes time of day or day of week. Pricing should be pluggable - a beach lot charges differently from an airport lot - but the cost calculation has to integrate cleanly with the ticket and exit flow.
Multi-level structure. A parking lot has levels (floors). Each level has spots. Vehicles navigate to a specific level. The model has to express the hierarchy without making navigation awkward or making capacity tracking expensive.
Capacity tracking. As spots are allocated and released, capacity counts change. Tracking these counts efficiently - and keeping display boards in sync - matters for performance and user experience. Real-time recompute vs precomputed counts is a design choice.
Concurrent access. Multiple entry and exit gates operate simultaneously. Two vehicles can approach two different entry gates at the same instant and both request a spot. The allocation has to be atomic - two vehicles cannot be assigned the same spot.
Each of these is a modeling decision. None of them are about implementation cleverness; all of them are about how the system represents the domain. This is what makes parking lot an OO interview problem rather than an algorithms problem.
Important: Parking Lot's modeling decisions dominate the interview signal. Steps 2 and 3 of the methodology - entities and class structure - generate roughly 50-60% of the total signal on this problem. Strong candidates spend disproportionate time there; weak ones rush past modeling to implementation and discover the model's gaps too late.
The Tensions That Make It Interesting
flowchart TB
subgraph T1[Tension 1: Vehicle Hierarchy Depth]
T1A[Deep inheritance]
T1B[Flat with enum/composition]
T1A <-.-> T1B
T1A --- T1AT[Type-specific behavior natural<br/>Rigid; hard to extend cross-cutting]
T1B --- T1BT[Flexible composition<br/>Type-specific behavior awkward]
end
subgraph T2[Tension 2: Where Compatibility Logic Lives]
T2A[Spot.canFit Vehicle]
T2B[Vehicle.fitsIn Spot]
T2A <-.-> T2B
T2A --- T2AT[Spot owns its capacity rules<br/>Spots need vehicle knowledge]
T2B --- T2BT[Vehicle owns its constraints<br/>Vehicles need spot knowledge]
end
subgraph T3[Tension 3: Allocation Strategy Coupling]
T3A[Strategy in ParkingLot]
T3B[Strategy injected as interface]
T3A <-.-> T3B
T3A --- T3AT[Simple; one strategy hardcoded<br/>Hard to extend with new strategies]
T3B --- T3BT[Pluggable; multiple strategies<br/>Indirection cost; more classes]
end
subgraph T4[Tension 4: Capacity Tracking Approach]
T4A[Recompute on demand]
T4B[Precomputed counters]
T4A <-.-> T4B
T4A --- T4AT[Always accurate; O(n) lookup<br/>Slow at scale]
T4B --- T4BT[O(1) lookup<br/>Synchronization burden]
end
style T1 fill:#fbbf24,stroke:#f59e0b,color:#000
style T2 fill:#34d399,stroke:#10b981,color:#000
style T3 fill:#f472b6,stroke:#ec4899,color:#fff
style T4 fill:#60a5fa,stroke:#3b82f6,color:#fff
Tension 1: Vehicle hierarchy depth. Inheritance (Vehicle → Car, Bike, Truck, EV) feels natural for "different kinds of vehicles," but inheritance hierarchies become rigid. What if a vehicle has multiple cross-cutting characteristics - a vehicle that is both Electric and Oversize? Multi-class inheritance creates ambiguity. Composition with capability interfaces (SupportsCharging, OversizeFootprint) handles cross-cutting concerns more flexibly but makes type-specific behavior awkward. The right choice depends on how the vehicle types actually vary.
Tension 2: Where compatibility logic lives. spot.canFit(vehicle) - the spot knows its own compatibility rules. vehicle.fitsIn(spot) - the vehicle knows its own constraints. Either works; both introduce a knowledge dependency in one direction. The choice affects how easy it is to add new vehicle types versus new spot types. There's no universally correct answer; there's an articulated choice with named trade-offs.
Tension 3: Allocation strategy coupling. Hardcoded allocation strategy ("first available compatible spot") is the simplest design but locks the lot into one allocation behavior. Injected Strategy interface allows multiple allocation behaviors - nearest, by-preference, time-of-day-based - at the cost of one more interface and one more injection point. The pluggable design earns its place when more than one strategy is realistically needed.
Tension 4: Capacity tracking approach. Recompute on demand - scan all spots when asked. Always accurate but O(n). Precomputed counters - maintained as spots change state. O(1) lookup but adds synchronization burden and the risk of counter drift if updates aren't atomic. The right answer depends on how often capacity is queried versus how often it changes.
These four tensions force modeling choices that strong candidates surface explicitly. Naming them - not just resolving them - is the senior signal.
The Domain Hierarchy and Lifecycle
The structural shape of the parking lot system:
flowchart TB
PL[Parking Lot]
L1[Level 1]
L2[Level 2]
LN[Level N]
S1[Spot 1A]
S2[Spot 1B]
S3[Spot 1C]
S4[Spot 2A]
S5[Spot 2B]
S6[Spot NA]
PL --> L1
PL --> L2
PL --> LN
L1 --> S1
L1 --> S2
L1 --> S3
L2 --> S4
L2 --> S5
LN --> S6
V[Vehicle Arrives]
T[Ticket Issued]
A[Spot Allocated]
P[Vehicle Parks]
E[Vehicle Exits]
F[Fee Calculated]
PMT[Payment]
R[Spot Released]
V --> T
T --> A
A --> P
P -.time passes.-> E
E --> F
F --> PMT
PMT --> R
R -.updates.-> S1
style PL fill:#a78bfa,stroke:#8b5cf6,color:#fff
style L1 fill:#60a5fa,stroke:#3b82f6,color:#fff
style L2 fill:#60a5fa,stroke:#3b82f6,color:#fff
style LN fill:#60a5fa,stroke:#3b82f6,color:#fff
style V fill:#34d399,stroke:#10b981,color:#000
style E fill:#fbbf24,stroke:#f59e0b,color:#000
The hierarchy (top half) shows ownership: a Lot has Levels which have Spots. The lifecycle (bottom half) shows the vehicle's journey through the system. The two interact at allocation (A) and release (R) - those are the points where the model and the lifecycle meet.
The structural simplicity is misleading. The complexity is in how the model represents each level of the hierarchy and how the lifecycle states transition.
How Real Systems Vary
Parking lot systems exist in many flavors, each with subtly different requirements:
Airport parking. Long-stay model. Pricing tiered by days. Often multiple zones (economy, daily, hourly, premium) with different rates. Reservations common. License-plate-recognition (LPR) entry/exit replacing physical tickets.
Mall parking. Mostly free or very cheap. Validation common (validate at a store for free parking). Usually short-stay. Capacity peaks on weekends.
Office parking. Reserved spots for employees. Pre-allocated based on parking permits. Visitor spots separate. Often access-controlled by employee badge.
Smart city street parking. Sensors per spot detect occupancy. App-based payment. Time limits enforced. Different from traditional lot model because spots are along streets, not in a structured facility.
Hospital parking. Multiple zones with different access levels (staff, patients, visitors, emergency). Discounted rates for some categories. Long-stay handling for hospitalized patients' families.
Stadium/event parking. Surge pricing on event days. Pre-paid passes. Capacity allocation between general public and premium ticket holders.
Valet parking. Different model entirely - humans drive the cars, so vehicle-to-spot mapping is system-controlled. Spots can be unstructured (any open patch of pavement).
The shared pattern: allocate scarce space to incoming entities, track duration, charge appropriately. The variations are in pricing model, allocation strategy, vehicle/spot vocabulary, and the entry/exit mechanisms.
An engineer who can model the canonical multi-level lot can adapt to any of these variations by swapping out the allocation strategy, the pricing strategy, and the vehicle/spot taxonomies. That's exactly what the case study optimizes for.
Important: The parking lot pattern recurs in any "allocate slots to incoming entities with duration-based fees" domain. Hotel rooms, airline seats, conference room booking, cloud compute instances, even concert tickets - they're all variations on the same core pattern. Learning to model parking lot teaches a pattern that transfers very broadly.
What This Problem Tests in Interviews
Beyond the surface skills, parking lot tests specific judgment calls that distinguish senior engineers:
Modeling judgment. The vehicle hierarchy choice. The spot compatibility location. The allocation strategy abstraction. The ticket lifecycle. Each is a modeling decision with named alternatives. Strong candidates make deliberate choices with articulated rationale; weak candidates make implicit choices that surface later as design debt.
Polymorphism fluency. This is the canonical "what does inheritance buy you" problem. Vehicles are the obvious polymorphism site. Spots are a secondary polymorphism site. Allocation and pricing are Strategy pattern sites. How candidates use polymorphism - and how they avoid over-using it - signals OO design depth.
Open-Closed Principle. "How would you add an electric vehicle with a charging requirement?" "How would you add a new pricing model for the weekend?" These probes test whether the design extends through addition or requires modification. The pluggable strategy patterns are what enable OCP-friendly extensions.
Multi-stakeholder thinking. Parking lot has multiple actors: drivers, attendants, administrators, security. Each interacts with the system differently. The model has to support each role without conflating them. Strong candidates explicitly think about stakeholder needs; weak ones design only for the driver flow.
State management. Spots have states (available, occupied, reserved). Tickets have states (active, paid, closed, lost). State transitions matter - invalid transitions are bugs. Strong candidates either use enum-with-validation or extract a State pattern explicitly.
Capacity tracking design. Real-time, multi-level, possibly multi-type. How the candidate handles this signals their ability to design for both correctness and performance.
These six judgments are what the parking lot interview actually tests. The six methodology steps that follow surface each one at the appropriate phase.
Common Misconceptions
Recurring misconceptions on this problem:
"Inheritance is the obvious answer for vehicles." It often is, but not always. Deep hierarchies become rigid. Cross-cutting characteristics (electric, oversize, premium) don't fit cleanly into a single inheritance chain. Strong candidates evaluate the alternatives and choose deliberately rather than defaulting.
"Just use a List of Spots and scan for compatibility." Works for small lots. Breaks at scale. The allocation strategy is a real design decision; treating it as "linear scan" misses the abstraction.
"Pricing is just hours * rate." Sometimes. More commonly: minimum charges, maximum daily caps, vehicle-type adjustments, validation discounts, time-of-day surcharges. Pricing benefits from being a pluggable strategy rather than a hardcoded calculation.
"State machines are over-engineering." True for simple states like occupied/available. False for ticket lifecycles where invalid transitions matter (you can't close a ticket that hasn't been paid, you can't pay for a ticket that's already closed). Some lifecycle modeling earns its place.
"Multi-level is just a List of Lists." Functionally yes, structurally no. Levels often have level-specific properties (height clearance, accessibility, security level). Modeling them as first-class entities is usually correct.
"Concurrency doesn't matter for a parking lot." It does. Two entry gates allocating spots simultaneously is a classic concurrency problem. Strong candidates address it; weak ones don't notice.
"The user-facing flow is the whole system." The administrator-facing flow (configuring rates, generating reports, handling exceptions) is significant in production. Strong candidates surface multi-stakeholder thinking.
Warning: The most common career-limiting misconception is treating vehicle polymorphism as the only important modeling decision. The other five - spot compatibility location, allocation strategy abstraction, pricing model, capacity tracking, multi-stakeholder design - are equally important and often more revealing of senior thinking.
The Roadmap: Six Steps Ahead
The rest of this case study walks the methodology applied to parking lot:
flowchart LR
T0[Topic 0<br/>The Problem<br/>You are here] --> S1[Step 1<br/>Requirements]
S1 --> S2[Step 2<br/>Core Entities]
S2 --> S3[Step 3<br/>Classes &<br/>Relationships]
S3 --> S4[Step 4<br/>Code<br/>Implementation]
S4 --> S5[Step 5<br/>Edge Cases<br/>& Tests]
S5 --> S6[Step 6<br/>Extensibility &<br/>Trade-offs]
style T0 fill:#a78bfa,stroke:#8b5cf6,color:#fff
style S1 fill:#34d399,stroke:#10b981,color:#000
style S2 fill:#60a5fa,stroke:#3b82f6,color:#fff
style S3 fill:#f472b6,stroke:#ec4899,color:#fff
style S4 fill:#fbbf24,stroke:#f59e0b,color:#000
style S5 fill:#34d399,stroke:#10b981,color:#000
style S6 fill:#818cf8,stroke:#6366f1,color:#fff
Step 1 - Requirements. The five high-leverage clarification questions for parking lot. Functional and non-functional requirements. Scope commitment. About 6-7 minutes.
Step 2 - Core Entities. The big modeling step for this problem. Vehicle hierarchy, spot polymorphism, ticket lifecycle, the eight entities. About 12 minutes - proportionally larger than for other problems because modeling is the centerpiece.
Step 3 - Classes & Relationships. Strategy patterns for allocation and pricing, the service layer, concurrency boundaries. About 9 minutes.
Step 4 - Code Implementation. Java implementation of allocate, release, calculateFee with polymorphism, strategy injection, and concurrency. About 10 minutes.
Step 5 - Edge Cases & Tests. Lot full, vehicle-spot mismatch, lost tickets, concurrent allocation race, lifecycle violations. About 5 minutes.
Step 6 - Extensibility & Trade-offs. Reservations, EV charging, dynamic pricing, multi-lot chains. Closing trade-offs.
How to Use This Case Study
Solo reading. All seven in order. About 100 minutes. The modeling depth in Step 2 is the section to spend extra time on - this is where parking lot's lessons concentrate.
With a study partner. After Topic 0, take turns playing interviewer and candidate. The dialogue sections in each step give you a benchmark.
As mock prep. Skim Topic 0 and Steps 1-3 for the methodology. Then practice end-to-end mocks. Review Steps 4-6 to compare your work to the case study's.
Exercise: Before diving into the six steps, do this 15-minute exercise:
Sketch the class hierarchy you would propose. Vehicles, spots, lot, level, ticket. Draw the relationships. Don't peek at Step 2.
Identify five modeling decisions you face. Vehicle hierarchy, spot compatibility location, allocation strategy, pricing, multi-level navigation, capacity tracking. For each, write the alternatives you'd consider.
Pick a vehicle hierarchy. Inheritance, enum, composition. Defend your choice for the most common LLD scope.
Predict the extensions the interviewer will probe. EV charging, reservations, dynamic pricing, what else?
Now read Step 1. Compare your sketch to what the strong candidate produces. The gap is your learning opportunity.
The next topic (Step 1) walks through the requirements phase for parking lot. Five clarification questions. Functional vs non-functional separation. The scope commitment. Strong-vs-weak dialogue. The work that opens about 25% of the total interview signal.