Design a Parking Lot

When BlackRock runs a design round, "design a parking lot" is a machine-coding prompt about craft rather than scale. The interviewer wants to watch you turn a fuzzy, everyday scenario into a clean set of classes with the right responsibilities. Then those classes have to behave correctly when two threads touch them at once. A parking lot is the most repeated version of this prompt here because everyone understands the domain instantly. That leaves the whole conversation for the modeling: what the entities are, how they relate, which operations they expose, and where the concurrency lives.

The parking lot earns its place because every layer of the skill shows up. 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 right there in the prompt. There's a real allocation decision. When a motorcycle arrives, which free spot does it take, and does that choice starve the buses that need the large ones later? There's 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 genuine concurrency. Cars enter and leave in parallel, so the counter that says a spot is free is the most contended thing in the system, and a lazy answer double-allocates it. Model those cleanly and the design reads as someone who writes production code. One giant class with a boolean array and no locking reads as someone who has only solved this on paper.

The BlackRock angle

BlackRock is a Java-backend org that lives and dies on correctness under concurrency, and a parking lot is where they probe that in miniature. The engineering here mostly builds and runs Aladdin, the platform that prices risk and moves client positions, so the room is full of interviewers who came up writing thread-dense code and grade it hard.