A parking lot question can tempt candidates to start listing classes immediately: Vehicle, Ticket, Gate, Floor, and Payment. A list of nouns is easy to produce. A low level design interview becomes more interesting when you explain which object owns a decision and which rules must survive every operation.
Begin with a small scope: vehicles enter, receive a compatible spot, and leave after their parking session is closed. Add reservations, pricing variations, or multiple gates only when the interviewer requests them. The exercise is to build a coherent model, not to guess every feature a real facility might someday need.
Simplified parking spot lifecycle for the article. Each transition must preserve the allocation rule.
Write the rules before the classes
One spot cannot belong to two active parking sessions at the same time. A vehicle should not receive a spot it cannot use. A completed session should not be closed again as if it were a new departure. These are invariants, and they tell you where the design needs protection.
Decide what identifies a session and what information must persist. A ticket number may refer to a session containing vehicle details, entry time, assigned spot, and status. A spot records its capabilities and availability. Payment records can remain separate so financial state does not become a boolean scattered across unrelated objects.
Put behavior beside the state it protects
An allocation service can select a compatible available spot. However, selection and claiming cannot be two uncoordinated operations when multiple gates are active. Explain how a repository or transaction boundary makes the claim atomic. The exact mechanism depends on whether the exercise is in memory or backed by a database.
Avoid allowing every caller to set spot status directly. Provide operations that enforce allowed transitions and return an explicit failure when a transition is invalid. This gives tests a clear contract and reduces the number of places that must remember the rules.
The diagram uses available, held, and occupied states. A hold can expire if entry is not completed. If the initial requirements do not need reservations, the hold can be a short internal allocation step rather than a public booking feature.
Make extension points earn their place
If pricing varies by vehicle type or time of day, a pricing policy can calculate a charge from a completed session. Keep that calculation separate from opening a gate. If the question has one fixed rate, a straightforward function may be enough until variation is introduced.
Similarly, an allocation policy can later prefer the nearest compatible spot. You do not need a design pattern name to justify the separation. Explain the behavior that is likely to change and the data it requires. That is more useful than adding interfaces to every class by default.
PhantomCodeAI's[https://www.phantomcodeai.com/interview-types/system-design-interview] system design resources describe both high level and low level design coverage. For this exercise, focus your rehearsal on object responsibilities and invalid operations instead of scaling the system to millions of requests.
Walk through the awkward cases
Ask what happens when two gates try to claim the last spot, a ticket is scanned twice, payment succeeds but the exit action fails, or a held spot is never occupied. You do not need to implement every recovery mechanism during the interview. You do need to show where each outcome is represented.
Test the model through its public operations. A successful allocation reduces available capacity exactly once. A rejected allocation changes nothing. Closing an already closed session has a defined result. These examples reveal the design more clearly than a large class diagram alone.
Finish by tracing one entry and one departure. The interviewer should be able to follow the state changes and see which component is responsible for preserving each rule.
Top comments (0)