Cruxly › Low-level design › Running the LLD Interview

Clarifying an LLD Prompt

turning four words into a finite model

Prompt: you are told, in full, "Design a parking lot." You have 45 minutes.

Before you write a single class name, what do you ask — and what do you do with the answers?

Why clarification is the graded part

Every LLD prompt is deliberately under-specified. That is not laziness on the interviewer's part — the under-specification is the test. A candidate who starts naming classes immediately has made a dozen assumptions silently, and the interview becomes a slow reveal of which ones were wrong.

The signal being measured: can you tell the difference between a requirement and an assumption? Every assumption you state out loud converts into a requirement you are allowed to build on. Every one you leave silent stays a liability.

The four questions that change the model

Ask these in roughly this order — each answer changes what the next one means.

@@ 1 | What are the entities, concretely? "Are there different vehicle sizes, and do they map to different spot sizes?"

A yes turns spot assignment from a queue pop into a fitting problem with a policy — can a motorcycle take a large spot when compacts are full? That single answer is worth ten minutes of design.

@@ 2 | What is the lifecycle? "Does a vehicle get a ticket on entry and pay on exit, or is it pre-booked?"

Entry/exit means the open-ticket invariant and a fee computed at exit. Pre-booking means reservations, a calendar, and overstay handling — a substantially bigger model, from the same four words.

@@ 3 | What varies later? "Is pricing flat, hourly, or does it differ by vehicle type?"

Anything that varies gets an interface; anything that doesn't gets a field. You're asking the interviewer to tell you where the seams go, and they will usually answer generously.

@@ 4 | Who calls this, and how many at once? "Is this one process serving multiple gates concurrently?"

Yes and you now owe a concurrency story on the assignment path. No and "I'll design single-threaded and note where locks would go" is a complete answer — one that protects you from a follow-up you didn't prepare for.

:::key Why this order, specifically Entities before lifecycle before variation before concurrency: each question's answer reshapes the vocabulary the next question is even asking about. Reorder them and you'll find yourself re-asking one you thought you already had. :::

What to do with the answers

Write them down visibly — shared doc, whiteboard — as a short list. Two reasons, both practical.

It anchors the conversation. When the interviewer adds a requirement forty minutes in, you point at the list and say what it changes. That reads as control, not defensiveness.

It protects you from scope creep you inflicted on yourself. Having "payment: out of scope" written down stops you from spending eight minutes on a PaymentProcessor nobody asked for — the single most common way candidates run out of time.

In scope:     one lot, multiple levels, three vehicle sizes,
              ticket on entry, fee on exit, hourly pricing
Out:          reservations, payment gateway integration,
              license plate recognition, multi-lot
Concurrency:  multiple gates, single process
Varies later: pricing rules, vehicle types

Four lines. Every later decision refers back to them.

The trap: asking questions as a ritual

There is a failure mode where a candidate, having read that asking questions is good, asks eight questions and then designs something unrelated to the answers. This is worse than not asking, because it demonstrates the habit without the understanding.

The test for whether a question is worth asking: can you name two designs that the answer would choose between? If you can't, you are performing. "Do we need to handle motorcycles?" is a real question — yes gives you a fitting policy, no gives you a uniform queue. "What's the expected traffic?" is usually not an LLD question at all; that's HLD, and asking it here signals you haven't understood which round you're in.

How to say it in the interview

"Before I model anything I want the scope closed: one lot or many, what vehicle types exist, whether payment is in scope, and whether this is single-threaded or serving concurrent gates. Those four answers decide four different designs."

Checklist

Closed the scope to a finite, written-down list before naming any class
Asked what entities and variants exist, not just what the system does
Established the object lifecycle — created when, closed when, by what event
Asked what is expected to change later, and put interfaces only there
Stated the concurrency model explicitly, even if the answer was single-threaded
Every question asked could name two designs it would choose between

Practice this interactively