Use this checklist on every object-oriented design question — it is the same shape whether the prompt is a parking lot, an elevator system, or a rate limiter.

Step 1: Clarify requirements and scope

Ask what the system must do (core use cases) before naming a single class. Confirm scale (single machine or distributed?), who the users/actors are, and what is explicitly out of scope. Skipping this step is the most common way to design the wrong thing well.

Step 2: Identify the core entities (nouns)

List the real-world objects the system needs to model — the nouns in the problem statement. For a parking lot: Vehicle, ParkingSpot, Ticket, Level. Do not model everything; only what the use cases in Step 1 require.

Step 3: Identify the actions (verbs) and assign responsibilities

For each use case, ask which entity is responsible for each action. This is the single-responsibility check: each class should own one clear piece of behavior, not become a catch-all.

Step 4: Define relationships between classes

Decide composition vs. inheritance, and cardinality (one Level has many ParkingSpots; one ParkingSpot has at most one Vehicle at a time). Draw it — a quick box-and-arrow diagram communicates more than a paragraph of description.

Step 5: Design for extensibility

State explicitly what should be easy to add later without rewriting the core: new vehicle types, new payment methods, new spot types. Favor interfaces/abstract base classes at the seams where variation is expected (strategy pattern for payment, factory for spot allocation) — but do not over-engineer variation nobody asked for.

Step 6: Walk through the use cases against your design

Trace 2–3 concrete scenarios through your class diagram end to end (a car enters, finds a spot, pays, leaves). This surfaces missing methods and awkward relationships before the interviewer has to point them out.

Step 7: Handle follow-ups

Common follow-ups: concurrency (two threads claiming the same spot — needs locking or atomic reservation), persistence (where does state live if the process restarts?), and API design (what would the public interface of this class look like to a caller?).

Related reading

• How to approach OOD interviews — the condensed version of this framework.