Free lesson · Low Level Design Interviews

Step 1: Requirements

Hard13 min readlldinterview-prepoop

Step 1 - Requirements

by Olena Marchenko - Software Engineer II, Microsoft Azure Developer Tools.

Of my 11 tech-interview rejections before Microsoft, at least four were on parking-lot-flavored problems. Variations of the same theme: design a multi-level parking system, design a hotel reservation system, design a meeting room booking system. The interviewer would say "implement the parking lot," and I would start coding. Within five minutes I'd be deep into a Vehicle class hierarchy with no idea how the spots were structured or what the pricing model was. Within fifteen, I'd realize my model couldn't accommodate something the interviewer assumed was obvious - electric charging, or reservations, or different pricing per spot type. The rejection feedback was always polite and unhelpful: "we feel you'd benefit from more practice with system design." What they meant was: you started solving before you understood what to solve.

That experience is why this step matters so much for parking lot specifically. The problem is broad. It has more dimensions of variability than most LLD interviews - vehicle types, spot types, pricing models, allocation strategies, level structures, payment methods, special handling, multi-stakeholder concerns. Without explicit scoping, candidates either drift into details that don't matter or skip details that do. The strong candidate uses 5-6 minutes to narrow the problem to a scope they can model rigorously in the remaining 40 minutes.

This step is about that requirements work. The interviewer's perspective on what to evaluate. The candidate's perspective on how to do it. The five to six clarifications that have the highest leverage. The scope commitment that locks the contract. And the strong-vs-weak conversation that shows the difference between deliberate scoping and ad-hoc drift.

The Interviewer's Perspective

When a candidate hears "design a parking lot system," I have a specific rubric in mind for the next 5-7 minutes:

Did they ask about the lot structure? Single level or multi-level? Single facility or chain? How big? The structural answer affects whether the candidate needs to model Level as a first-class entity and how navigation between levels works.

Did they ask about vehicle types? "Cars only" is a very different problem than "Cars, Bikes, Trucks, EVs, Motorcycles, Limousines." The number and variety of vehicle types determines how complex the polymorphism gets and whether composition might beat inheritance. Strong candidates ask for the specific list and then commit to a closed set.

Did they ask about spot types and compatibility? Compact, Regular, Large, Handicap, EV-Charging, Reserved. Which exist? How do they compatibility-relate to vehicle types? "A bike fits anywhere; a car fits regular and large; a truck fits only large" is a typical compatibility rule, but it has to be elicited, not assumed.

Did they ask about the pricing model? Hourly, daily, tiered, vehicle-type-based, time-of-day-variable? This is one of the most variability-rich dimensions of parking lots - and one most candidates skip entirely. A candidate who asks "what's the pricing model?" before designing is signaling that pricing is a real modeling concern, not an implementation detail.

Did they ask about concurrency? Multiple entry/exit gates operating simultaneously? The answer drives the lock granularity decision later. Strong candidates surface this; weak ones assume single-threaded.

Did they ask about reservations or special handling? Pre-booked spots, handicap permits, employee reserved, valet zones? Each is a scope-expanding feature. The candidate doesn't need to handle all of them, but should clarify which (if any) are in scope.

Did they commit to a scope? 60-second articulation: how many levels, which vehicle types, which spot types, what pricing model, concurrency yes/no, what's out of scope.

The requirements phase for parking lot generates about 25-30% of the interviewer's total signal. The breadth of the problem makes the scoping step more consequential than usual. A candidate who locks the scope cleanly has a tractable problem; one who doesn't has 40 minutes of drift ahead.

Important: Parking lot has the broadest scoping surface of common LLD problems. Five to six clarifications can transform an unbounded problem into a tractable one. Skipping this step is the single most damaging requirements failure on parking lot.

The Candidate's Perspective

The requirements phase for parking lot has specific shape because the problem is wide:

Resist the simplicity assumption. The problem sounds like a junior question. It isn't. Treat it as a serious modeling problem and the requirements phase deserves real time.

Open with the structural question. "Multi-level or single-level?" That single answer determines whether Level is a first-class entity. Get it early.

Establish the vehicle-and-spot vocabulary. "Which vehicle types do we support? Which spot types? What are the compatibility rules between them?" These three questions together set the polymorphism scope.

Surface the pricing dimension. "What's the pricing model? Flat hourly? Vehicle-type-based? Time-of-day-variable?" Pricing is one of the easiest things to defer to implementation, but doing so guarantees you'll under-design the abstraction.

Address concurrency explicitly. "Do multiple entry/exit gates operate concurrently?" If yes, the allocation needs atomic semantics. If no, simpler.

Catch the feature dimension. Reservations, EV charging, special permits, payment methods - name what's in and what's out before committing to a scope.

Use the trade-off framing in questions. "Should the pricing model be pluggable? I'm asking because if pricing varies - by time, by vehicle, by lot - a Strategy interface earns its place; if it's a single fixed formula, hardcoding is fine."

Commit explicitly. End with a scope commitment. "Multi-level, three vehicle types, four spot types with named compatibility, hourly pricing varied by spot type, concurrent gates, no reservations, payment abstracted. Does that match?"

The candidate's job is to convert a deliberately broad problem into a tractable scope while demonstrating modeling awareness through the questions themselves.

Applied to Parking Lot

The requirements phase has specific shape for this problem.

Functional requirements worth surfacing

A typical parking lot system exposes:

• Vehicle entry. Identify vehicle, check capacity, allocate a spot, issue ticket.
• Vehicle exit. Validate ticket, calculate fee, process payment, release spot.
• Capacity query. Real-time available count by spot type and level.
• Spot status. Available, occupied, reserved, out-of-service.
• Lost ticket handling. Different fee calculation (typically a flat penalty).
• Administrator operations. Configure rates, mark spots out-of-service, view reports.

The candidate should articulate which of these are in scope. Driver-facing flows are core; administrator flows are often out of scope.

Non-functional requirements that shape the design

Time complexity. Allocation should be reasonably fast - O(1) per spot type with precomputed availability, or O(n) over a level's spots without. The candidate should articulate the approach.

Thread safety. Multiple gates, concurrent operations. The lock granularity decision permeates the design.

Capacity scale. A small lot (~100 spots) and a large lot (~10,000 spots) have very different design pressures. Capacity tracking in particular matters more at scale.

Extensibility. Pluggable allocation strategy. Pluggable pricing model. Open-Closed Principle compliance for new vehicle types and spot types.

Multi-stakeholder. Driver flow, attendant flow, administrator flow. Not all in scope but worth naming.

The high-leverage clarification questions

If I'm the candidate, I'd ask these five to six questions in roughly this order:

1. "Is this a multi-level parking lot, or single level? And single facility or part of a chain?" Determines whether Level is a first-class entity and whether the design has to scale across lots.

2. "What vehicle types do we support? And what are the compatibility rules with spot types?" Anchors the polymorphism scope. Closed set is critical - open-ended vehicle types make the model unbounded.

3. "What's the pricing model? Flat hourly? Vehicle-type-based? Time-of-day-variable? Are there special cases like daily caps or minimum charges?" Determines whether pricing is a hardcoded calculation or a Strategy interface.

4. "Do multiple entry and exit gates operate concurrently? If so, how many?" Drives the concurrency model.

5. "What's the spot allocation strategy preference? First available? Nearest to entry? By vehicle type preference?" Determines whether allocation is hardcoded or pluggable.

6. "Are reservations, special permits, or EV-charging in scope? Payment methods to support?" Catches the feature dimension.

That's five to six questions in 4-5 minutes. Each shapes a specific design decision. The scope commitment follows.

The scope commitment

A strong candidate's scope commitment for parking lot might sound like:

"Based on those answers: I'm modeling a single multi-level facility, three levels each with mixed spot types. Three vehicle types - Car, Bike, Truck - with named compatibility rules. Spot types: Compact, Regular, Large, Handicap. Hourly pricing varied by spot type, with a max daily cap. Concurrent entry/exit gates - two entry, two exit. Allocation strategy is 'first available compatible spot' but designed for extension to other strategies. No reservations, no EV charging in scope but I'll note the extension seams. Payment abstracted behind a PaymentProcessor interface - I won't implement the processor itself. Does that match what you want?"

About 75 seconds. Locks the scope across all the variability dimensions. The interviewer confirms or pushes back.

How to Decide What to Ask

The clarification prioritization for parking lot:

flowchart TD
    Q[Clarification Question] --> A{Does the answer change<br/>the model fundamentally?}
    A -->|Yes - architectural impact| H[High Leverage<br/>Ask First]
    A -->|Maybe - feature scope| M[Medium Leverage<br/>Ask If Time]
    A -->|No - implementation detail| L[Low Leverage<br/>Skip]
    
    H --> H1[Multi-level or single?]
    H --> H2[Vehicle types and compatibility]
    H --> H3[Pricing model]
    H --> H4[Concurrent gates?]
    H --> H5[Allocation strategy]
    
    M --> M1[Reservations]
    M --> M2[EV charging]
    M --> M3[Special permits]
    M --> M4[Payment methods]
    M --> M5[Lost ticket handling]
    
    L --> L1[Programming language]
    L --> L2[Database choice]
    L --> L3[UI framework]
    L --> L4[Logging library]
    
    style H fill:#34d399,stroke:#10b981,color:#000
    style M fill:#fbbf24,stroke:#f59e0b,color:#000
    style L fill:#f87171,stroke:#ef4444,color:#000

Discipline: five High Leverage questions, maybe one or two Medium Leverage if time allows. Skip the Low Leverage entirely. For parking lot, more than seven questions usually means over-clarification.

The Conversation

What the requirements phase actually sounds like.

Strong Candidate

Interviewer: "Design a parking lot system."

Candidate: [8-second pause to think] "Parking lot has more design dimensions than most LLD problems, so I want to scope a few before I start modeling.

First: is this a multi-level parking lot or single level? And is it a single facility, or do we need to think about multiple facilities in a chain?"

Interviewer: "Single multi-level facility. Three levels."

Candidate: "Good. So Level becomes a first-class entity in my model. Second: what vehicle types do we support, and what are the compatibility rules with spot types?"

Interviewer: "Cars, Bikes, Trucks. Bikes fit in any spot. Cars need Regular or Large spots. Trucks need only Large spots."

Candidate: "Got it. Three vehicle types with named compatibility - clean enough for inheritance hierarchy or for an enum-based approach. I'll decide that in modeling. Third: pricing model. Flat hourly? Vehicle-type-based? Time-of-day-variable? Caps?"

Interviewer: "Hourly rate, varied by spot type. Compact spots cheapest, Large spots most expensive. Cap at 24 hours flat-rate daily max."

Candidate: "Pricing varies by spot type - that means I'll abstract pricing behind a Strategy interface rather than hardcoding. The daily cap is interesting; I'll handle it explicitly in the calculation. Fourth: do multiple entry and exit gates operate concurrently?"

Interviewer: "Two entry gates, two exit gates, all concurrent."

Candidate: "Concurrency is in scope. I'll design for atomic spot allocation. Fifth: spot allocation strategy preference? First available? Nearest to entry? By vehicle preference?"

Interviewer: "First available compatible spot is fine for now, but make sure the design accepts other strategies."

Candidate: "Got it. I'll inject the allocation strategy via an interface - 'first available' is the default but it's pluggable. Sixth: reservations, EV charging, special permits, payment methods?"

Interviewer: "Out of scope but note the extension seams. Payment is abstracted - assume a PaymentProcessor interface; you don't need to implement it."

Candidate: "Okay, let me commit to a scope before I move on.

I'm designing a single multi-level facility with three levels and mixed spot types per level. Three vehicle types - Car, Bike, Truck - with named compatibility. Four spot types - Compact, Regular, Large, Handicap. Hourly pricing varied by spot type, daily cap at 24-hour flat rate. Two entry gates and two exit gates, all concurrent. Allocation strategy pluggable via interface, default is first-available-compatible. No reservations, no EV charging, no special permits in scope - extension seams noted. Payment abstracted behind a PaymentProcessor interface. Does that match what you want?"

Interviewer: "Yes. Continue."

About 5 minutes. Six clarification questions, each shaping a specific design dimension. Scope commitment locks the contract. The interviewer has clear visibility into what the candidate will model. The remaining 40 minutes have direction.

Weak Candidate

Interviewer: "Design a parking lot system."

Candidate: "Okay. I'll have a ParkingLot class. It'll have a list of ParkingSpot objects. There will be a Vehicle class, and it'll have subclasses for Car, Bike, Truck. When a vehicle comes in, we find an available spot and assign it."

Interviewer: [20 seconds in] "Do you want to clarify anything?"

Candidate: "Oh. What's the size of the lot?"

Interviewer: "Let's say a few hundred spots."

Candidate: [continues sketching] "Okay. And the ParkingSpot will have a status - available or occupied. When a vehicle is assigned, we mark it occupied."

Interviewer: "What about multiple levels?"

Candidate: "Oh. There can be multiple levels? Hmm. Then I guess ParkingLot has a list of Levels, and each Level has a list of ParkingSpots."

Interviewer: "What about pricing?"

Candidate: "Right, I forgot pricing. I'll have a rate per hour, and when the vehicle exits, we calculate hours times rate."

Interviewer: "What if different spot types have different prices?"

Candidate: "I... I can put the rate on the ParkingSpot."

Interviewer: "What if the pricing changes by time of day?"

Candidate: "Then I'd need... a method to compute the rate?"

Interviewer: "What about concurrent access?"

Candidate: "Oh, right. I'll add synchronized to the methods."

Interviewer: "Where? On ParkingLot? On Level? On ParkingSpot?"

Candidate: "Um. On ParkingLot, I guess."

Interviewer: "Okay. What about reservations?"

Candidate: "Reservations would be a different feature, I think. Out of scope for now?"

Interviewer: "Sure. Continue."

About 5 minutes. The candidate started designing before clarifying. The interviewer ended up driving every clarification - multi-level, pricing variation, concurrency, reservations. By the end, the candidate has implicit answers to questions they didn't ask, and the interviewer's read is: "didn't think to clarify; will likely miss requirements that aren't surfaced."

Strong vs Weak: Questions and Statements

The pattern: strong candidates use clarification to map the problem's design space before committing to a solution. Weak candidates jump to a solution and then discover the design space through interviewer corrections.

Common Mistakes

The parking lot requirements failures I see most often:

Skipping requirements entirely. "It's a parking lot. I know how to design that." Producing a Vehicle class hierarchy in 90 seconds without any scoping. The candidate then has to refactor their model multiple times as the interviewer surfaces requirements.

Asking only about size. "How many spots?" Treating capacity as the only variable. Missing structure, vehicle types, pricing, concurrency, allocation.

Asking about implementation details. "Should I use Java or Python?" "Should I use a database?" Conflating requirements with implementation choices.

Assuming single-level. Designing for a flat list of spots, then having to retrofit Level as a first-class entity when the interviewer probes multi-level.

Skipping pricing. Treating pricing as an implementation detail. Missing the Strategy abstraction opportunity.

Skipping concurrency. Designing without thinking about concurrent gates. Producing a single-threaded model that doesn't handle the multi-gate case.

Over-clarifying on features. Asking about every possible extension - valet, reservations, employee parking, monthly passes, vouchers - burning the clarification budget.

No scope commitment. Asking questions, receiving answers, then drifting into design without explicitly stating the scope. The contract never gets locked.

Warning: The most damaging requirements failure on parking lot is treating it as a simple problem and skipping the scoping. The problem's breadth means undeclared scope causes design rework at minute 20, minute 30, minute 40 - each rework eroding the candidate's signal further.

What "Good" Looks Like

Concrete signals I score positively in the requirements phase:

A short pause before any clarification. 8-15 seconds. Signals reading, not template execution.

Functional and non-functional separation. "Functionally: entry, exit, capacity query. Non-functionally: O(1) capacity check, thread safety, pluggable pricing and allocation, extensibility for new vehicle/spot types."

Five to six targeted questions. In priority order. Structure, vehicle/spot vocabulary, pricing, concurrency, allocation strategy, features.

Trade-off awareness in the questions. "Should pricing be pluggable? I'm asking because if pricing varies by time or vehicle, Strategy earns its place; if not, hardcoding is fine."

Active acknowledgment of answers. "Multi-level - so Level is a first-class entity. Pricing varies by spot type - Strategy interface, not hardcoded. Concurrent gates - atomic allocation."

Explicit scope commitment. 60-75 second articulation ending with "does that match?"

Multi-stakeholder awareness. Even briefly: "I'm focusing on driver and entry/exit flows; administrator operations are out of scope."

Clean transition out. "Okay, with scope locked, let me move to the entity model - I want to think carefully about the vehicle hierarchy and spot compatibility."

A candidate hitting six or seven of these signals in 5-6 minutes has produced senior requirements work.

Try It

Exercise: Drill the requirements phase for parking lot:

1. Build the six-question checklist. Structure, vehicle/spot vocabulary, pricing, concurrency, allocation, features. Drill until you can produce them in 90 seconds.

2. Practice the scope commitment. Have a mock partner play interviewer with varied answer sets. Produce a 75-second scope commitment each time.

3. Practice extension-bounding. "Reservations, EV charging, special permits are out of scope but I'll note the seams." Practice saying it crisply.

4. Drill the trade-off framings. "I'm asking because if X, then Y; otherwise Z." Make trade-off awareness audible in every question.

5. Audit your filler. Record your requirements phase. Listen for "um, what about..." discovery questions and replace them with structured, priority-ordered clarifications.

The next step (Step 2) covers core entity modeling - the centerpiece of parking lot. Vehicle hierarchy, spot compatibility, ticket lifecycle, the eight entities. The scope you committed to here becomes the input to that work.

Back to Low Level Design Interviews