Search
⌘K
Get Premium
Early Access
Common Problems
Parking Lot
Understanding the Problem
🚗 What is a Parking Lot System?
A parking lot system manages vehicle parking across multiple spots. When a vehicle enters, the system assigns an available spot matching the vehicle type and issues a ticket. When the vehicle exits, the system calculates the parking fee based on time spent and frees up the spot for the next customer.
Requirements
When you walk into the interview, you'll probably get something like this:
"Design a parking lot system where different types of vehicles can park, and the system manages spot assignment and calculates fees upon exit."
Before you start thinking about classes, you need to nail down exactly what you're building. Spend a few minutes asking questions to turn this into something more concrete.
Clarifying Questions
Structure your questions around what the system does, how it handles mistakes, what's in scope, and what might change later.
Here's how the conversation might go:
You: "So when a vehicle enters, the system assigns it a specific spot automatically?" Interviewer: "Yes, the system assigns an available spot matching the vehicle type and issues a ticket."
You might be thinking, "what kind of parking lot assigns a specific spot when you drive in?" Fair question. Most real parking lots let you pick your own spot. But the assigned-spot version is how this problem gets asked in interviews because it forces you to design the allocation logic. I agree it's goofy, but just roll with it.
You: "What types of vehicles does the system support? Just cars, or do we need motorcycles, trucks, that kind of thing?"Interviewer: "Three types. Motorcycles, regular cars, and large vehicles like SUVs or vans."
Good. Now you know the vehicle categories and that the system controls spot assignment.
You: "What happens when the vehicle enters? Do they get a ticket, a code, or something else to prove they parked there?"Interviewer: "They get a ticket with a unique ID. They'll need that ticket to exit."
Now you know the entry flow.
You: "How does pricing work? Is it hourly, flat rate, different rates for different vehicle types?"Interviewer: "Keep it simple. Hourly rate, same for all vehicles. Round up to the nearest hour and they pay when they leave."
When the interviewer says "keep it simple," that's your signal to not over-engineer. Don't build a complex pricing engine with surge pricing and discounts unless they explicitly ask for it.
You: "What happens if the lot is full when someone tries to enter? Or if they try to exit with an invalid ticket?"Interviewer: "Reject entry if there's no compatible spot available. For exit, return an error if the ticket is invalid or already used."
Good error handling clarity.
You: "What if someone loses their ticket? Do we need to handle that case?"Interviewer: "Good question, but let's keep it simple. Just assume they never lose their ticket for now."
Interviewers notice when you ask about edge cases and failure modes. Questions like "what if they lose the ticket?" or "what happens when the system is full?" show you're thinking about real-world problems. Don't go overboard with 20 edge cases, but getting into the habit of asking "what can go wrong?" signals mature engineering thinking.
You: "Last question. What's out of scope? Are we worrying about payment processing, entrance gates, cameras, that kind of infrastructure?"Interviewer: "No. Focus on the core logic. Spot assignment, ticket management, fee calculation. Skip the physical hardware, payment systems, and UI."
Perfect. You've scoped out what not to build.
Final Requirements
After that back-and-forth, you'd write this on the whiteboard:
Final Requirements
Requirements:
1. System supports three vehicle types: Motorcycle, Car, Large Vehicle
2. When a vehicle enters, system automatically assigns an available compatible spot
3. System issues a ticket at entry.
4. When a vehicle exits, user provides ticket ID
- System validates the ticket
- Calculates fee based on time spent (hourly, rounded up)
- Frees the spot for next use
5. Pricing is hourly with same rate for all vehicles
6. System rejects entry if no compatible spot is available
7. System rejects exit if ticket is invalid or already used
Out of scope:
- Payment processing
- Physical gate hardware
- Security cameras or monitoring
- UI/display systems
- Reservations or pre-bookingCore Entities and Relationships
Now that requirements are clear, you need to figure out what objects make up your system. Look for nouns in your requirements, but don't turn every noun into a class. Some things are just data.
Class Design
ParkingLot
ParkingSpot
Ticket
Final Class Design
Implementation
ParkingLot
ParkingSpot
Ticket
Complete Code Implementation
Verification
Extensibility
1. "How would you extend this to a multi-floor parking garage?"
2. "How would you add different pricing for different vehicle types?"
3. "How would you handle multiple entrances with concurrent access?"
What is Expected at Each Level?
Junior
Mid-level
Senior
Purchase Premium to Keep Reading
Unlock this article and so much more with Hello Interview Premium
Purchase PremiumCurrently up to 25% off
Hello Interview Premium
Reading Progress
On This Page
Understanding the Problem
Requirements
Clarifying Questions
Final Requirements
Core Entities and Relationships
Class Design
ParkingLot
ParkingSpot
Ticket
Final Class Design
Implementation
ParkingLot
ParkingSpot
Ticket
Complete Code Implementation
Verification
Extensibility
1. "How would you extend this to a multi-floor parking garage?"
2. "How would you add different pricing for different vehicle types?"
3. "How would you handle multiple entrances with concurrent access?"
What is Expected at Each Level?
Junior
Mid-level
Senior
Schedule a mock interview
Meet with a FAANG senior+ engineer or manager and learn exactly what it takes to get the job.