Object-Oriented Parking Lot Design with Check-In and Check-Out

Quick Overview

An object-oriented design interview question asking you to model a parking lot and implement working check-in and check-out methods. It tests class design and relationships, fast free-spot lookup across vehicle sizes, ticket handling, fees, edge cases, and thread safety.

Object-Oriented Parking Lot Design with Check-In and Check-Out

Company: Uber

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: hard

Interview Round: Onsite

Design a parking lot in an object-oriented style and implement its two core operations: - `check_in`: a vehicle arrives. Assign it a free spot it fits in, and give the driver something to present when leaving, such as a ticket. If no suitable spot is free, report that clearly. - `check_out`: the vehicle leaves. Release its spot and close out the visit. Write runnable code for these methods and the classes they need, and handle the edge cases. ```hint Start from the two methods Write the signatures of check-in and check-out first, and list what each one must look up. That tells you which classes and which indexes you actually need. ``` ```hint Finding a free spot fast Scanning every spot on each check-in works but is slow for a large lot. Consider what you could maintain so that "a free spot that fits this vehicle" is cheap to find and cheap to give back. ``` ### Clarifying Questions - Which vehicle types and spot sizes exist, and can a smaller vehicle use a larger spot? - Does check-out compute a fee? If so, what is the pricing rule? - What does check-in return: a ticket, a spot, or an error when the lot is full? - Does the lot have several levels, and does the spot assignment policy matter (nearest to the entrance, lowest level, smallest fitting spot)? - Can several entrances and exits call these methods at the same time? - What should happen if a vehicle that is already parked checks in again, or if an unknown or already used ticket is presented at check-out? ### What a Strong Answer Covers - Scope agreed after clarification: vehicle and spot types, fees, levels and assignment policy - Classes with clear responsibilities and well-defined relationships - Correct, runnable `check_in` and `check_out` with an efficient free-spot lookup - Edge cases: a full lot, duplicate check-in, unknown or reused tickets, size mismatches - Extensibility (pricing rules, new vehicle types) and thread safety ### Follow-up Questions - Add pricing that differs by vehicle type and time of day. Which class changes? - Two entrances check in vehicles at the same moment. How do you guarantee they never get the same spot? - Add a display that shows free spots per level and per size. - How would you support reservations made ahead of arrival?

Overview: An object-oriented design interview question asking you to model a parking lot and implement working check-in and check-out methods. It tests class design and relationships, fast free-spot lookup across vehicle sizes, ticket handling, fees, edge cases, and thread safety.

|Home/Software Engineering Fundamentals/Uber
Uber logo
Uber
Sep 29, 2026
hardSoftware EngineerOnsiteSoftware Engineering Fundamentals
0
0

Design a parking lot in an object-oriented style and implement its two core operations:

  • check_in : a vehicle arrives. Assign it a free spot it fits in, and give the driver something to present when leaving, such as a ticket. If no suitable spot is free, report that clearly.
  • check_out : the vehicle leaves. Release its spot and close out the visit.

Write runnable code for these methods and the classes they need, and handle the edge cases.

Clarifying Questions Guidance

  • Which vehicle types and spot sizes exist, and can a smaller vehicle use a larger spot?
  • Does check-out compute a fee? If so, what is the pricing rule?
  • What does check-in return: a ticket, a spot, or an error when the lot is full?
  • Does the lot have several levels, and does the spot assignment policy matter (nearest to the entrance, lowest level, smallest fitting spot)?
  • Can several entrances and exits call these methods at the same time?
  • What should happen if a vehicle that is already parked checks in again, or if an unknown or already used ticket is presented at check-out?

What a Strong Answer Covers Guidance

  • Scope agreed after clarification: vehicle and spot types, fees, levels and assignment policy
  • Classes with clear responsibilities and well-defined relationships
  • Correct, runnable check_in and check_out with an efficient free-spot lookup
  • Edge cases: a full lot, duplicate check-in, unknown or reused tickets, size mismatches
  • Extensibility (pricing rules, new vehicle types) and thread safety

Follow-up Questions Guidance

  • Add pricing that differs by vehicle type and time of day. Which class changes?
  • Two entrances check in vehicles at the same moment. How do you guarantee they never get the same spot?
  • Add a display that shows free spots per level and per size.
  • How would you support reservations made ahead of arrival?
Loading comments...