LeetCode Problem Workspace
Design Parking System
Implement a class to manage a parking lot with fixed slots for big, medium, and small cars, tracking occupancy efficiently.
3
Topics
8
Code langs
3
Related
Practice Focus
Easy · Design plus Simulation
Answer-first summary
Implement a class to manage a parking lot with fixed slots for big, medium, and small cars, tracking occupancy efficiently.
Ace coding interviews with Interview AiBoxInterview AiBox guidance for Design plus Simulation
This problem requires designing a ParkingSystem class that tracks available slots for three car types. Each addCar call must check availability and update counts. It tests simulation skills, careful state management, and counting logic for constrained resources.
Problem Statement
Design a parking system for a lot with three types of spaces: big, medium, and small. Each type has a fixed number of slots, and cars must only park in their corresponding type if space is available.
Implement the ParkingSystem class with a constructor to initialize slot counts and an addCar method to check availability and update counts. Return true if a car can park, false otherwise. Example: ParkingSystem(1,1,0) allows one big and one medium car, no small car slots.
Examples
Example 1
Input: See original problem statement.
Output: See original problem statement.
Input ["ParkingSystem", "addCar", "addCar", "addCar", "addCar"] [[1, 1, 0], [1], [2], [3], [1]] Output [null, true, true, false, false]
Explanation ParkingSystem parkingSystem = new ParkingSystem(1, 1, 0); parkingSystem.addCar(1); // return true because there is 1 available slot for a big car parkingSystem.addCar(2); // return true because there is 1 available slot for a medium car parkingSystem.addCar(3); // return false because there is no available slot for a small car parkingSystem.addCar(1); // return false because there is no available slot for a big car. It is already occupied.
Constraints
- 0 <= big, medium, small <= 1000
- carType is 1, 2, or 3
- At most 1000 calls will be made to addCar
Solution Approach
Maintain Slot Counters
Keep separate counters for big, medium, and small slots. On initialization, set each counter to the provided slot numbers. This ensures O(1) access and updates for each addCar call.
Simulate Parking Operations
For each addCar call, check if the requested car type has an available slot. If so, decrement the counter and return true; otherwise, return false. This directly models the parking system behavior.
Edge Case Handling
Ensure carType values outside 1-3 are rejected if constraints are loosened, and handle cases where slots are zero initially. Properly simulate repeated addCar calls until slots are exhausted to avoid logical errors.
Complexity Analysis
| Metric | Value |
|---|---|
| Time | O(N) |
| Space | O(1) |
Time complexity is O(N) for N addCar calls since each operation is O(1). Space complexity is O(1) because only three counters are stored regardless of N.
What Interviewers Usually Probe
- Check if the candidate tracks slot availability correctly for each car type.
- Observe whether addCar updates the internal state without overwriting counts.
- See if the candidate handles repeated calls after slots are full efficiently.
Common Pitfalls or Variants
Common pitfalls
- Mixing up car type indices leading to wrong counter updates.
- Failing to return false when a slot is already occupied.
- Not correctly handling edge cases where initial slots are zero.
Follow-up variants
- Extend to support dynamic slot addition and removal after initialization.
- Modify for multiple parking lots with shared cars types across lots.
- Track parking history to determine peak usage per car type.
FAQ
What is the primary pattern in Design Parking System?
The problem follows a Design plus Simulation pattern where you model a system and track state changes over time.
How do I handle multiple addCar calls efficiently?
Use simple counters for each car type and decrement them on successful parking to maintain O(1) operations.
Can carType values outside 1-3 appear?
Constraints guarantee carType is 1, 2, or 3, but defensive coding can check bounds if extended.
What should I return when no slots are available?
Return false to indicate the car cannot park in that type.
Why is this problem related to Counting and Simulation?
You must count remaining slots and simulate addCar calls, reflecting state changes accurately for each type.
Solution
Solution 1: Simulation
We use an array $\textit{cnt}$ of length 4 to represent the number of parking spaces for each type of car, where $\textit{cnt}[1]$, $\textit{cnt}[2]$, and $\textit{cnt}[3]$ represent the number of large, medium, and small parking spaces, respectively.
class ParkingSystem:
def __init__(self, big: int, medium: int, small: int):
self.cnt = [0, big, medium, small]
def addCar(self, carType: int) -> bool:
if self.cnt[carType] == 0:
return False
self.cnt[carType] -= 1
return True
# Your ParkingSystem object will be instantiated and called as such:
# obj = ParkingSystem(big, medium, small)
# param_1 = obj.addCar(carType)Continue Topic
design
Practice more edge cases under the same topic.
arrow_forwardauto_awesomeContinue Pattern
Design plus Simulation
Expand the same solving frame across more problems.
arrow_forwardsignal_cellular_altSame Difficulty Track
Easy
Stay on this level to stabilize interview delivery.
arrow_forward