Object-Oriented Design: Parking Lot

When Goldman runs a design round, it's most often object-oriented machine coding. The prompt usually comes in the firm's own words: identify all the classes, their member variables and their methods, then build the core behavior. A parking lot is the canonical version of that prompt because everyone understands the domain instantly, so the whole conversation is about the modeling rather than the scenario. The interviewer is not asking you to serve a billion drivers. They want to see you turn a fuzzy, everyday situation into a clean set of classes with the right responsibilities. Then those classes have to behave when two threads touch them at once.

The parking lot stands in for a whole family of prompts. A snake-and-ladder board asks for the same identify-the-classes move: a board of cells, snakes and ladders that move a player, a dice that advances a turn, and a game that runs the loop. A conference-room allocator asks for it too, with rooms and bookings over time intervals and a scheduler that grants or refuses a slot. Learn the method on the parking lot and you can carve any of them. The sections below teach the procedure and use the lot as the worked case.

The parking lot earns that role because every layer of the skill shows up honestly. There's obvious entity modeling. Vehicles come in sizes, spots come in sizes, and a ticket ties a vehicle to a spot for a span of time, so the nouns are sitting right there in the prompt. There is a real allocation decision: when a motorcycle arrives, which of the free spots does it take, and does that choice starve the buses that need the large ones later. There is state to track: how many spots of each size are free, updated on every entry and exit, and reported the instant someone asks. And there's real concurrency. Cars enter and leave in parallel, so the free-spot counter is the most contended thing in the system, and a lazy answer double-allocates it. Model those cleanly and the design shows you write production code.