The Sentence That Has to Come Before Any Requirement
Why leading a design interview with a feature list instead of a business objective loses the interviewer before you've written a single class, using BookMyShow as the worked example.
You're asked to design BookMyShow, a movie ticket booking platform. Before you touch a single requirement, before you sketch a single class, there's one sentence you owe the interviewer.
Skip it, and everything you say for the rest of the interview sounds like a script instead of a conversation.
The Trap: Answering With Requirements When You're Asked for an Overview
Every design interview opens the same way. You're told what to design. In that first breath, you have to decide whether you actually know what the system is.
That's a real fork, not a formality. If you don't know the system, ask. If you do know it, don't ask anyway.
Asking anyway wastes the interviewer's time and signals you can't drive a conversation on your own.
The trickier failure shows up when you do know the system but open with the wrong sentence anyway.
"So this should support booking across every city, every theatre, every seat in the country?"
This names features before anyone has agreed on what the product even is.
"I assume this is a movie booking platform, one that lets people book seats for movies in theatres. Is that what you want me to design?"
This states the business objective and waits for confirmation.
Say What the System Is, in One Sentence, Before Anything Else
The fix is almost embarrassingly simple. Before any clarifying question, state the business objective in one plain sentence and let the interviewer confirm it.
For BookMyShow, that sentence is the good card above.
Notice what that sentence does and doesn't do. It doesn't mention cities, doesn't mention seat counts, doesn't mention databases. It exists purely to align two people on what the product fundamentally is, before either of them talks about how it works.
Once the interviewer confirms it, something shifts. You're no longer guessing at scope in the dark. The interviewer, in turn, now knows you can summarize a system in one sentence instead of drowning it in detail.
That's a small thing to demonstrate in the first thirty seconds. It's exactly why it matters.
Three Questions That Come Right After Alignment
Only after that one-sentence alignment should the actual clarifying questions start, and they follow a fixed shape regardless of which system you're designing:
- Scope: Do you want me to model just the entities involved, like movies and theatres, or build out a real system with tickets, payments, and refunds too?
- Interface: Should the system expose an API, take input from the command line, or just hardcode inputs in the main file for now?
- Persistence: Should this connect to a real database, or is in-memory storage fine for the scope of this exercise?
The second question hides a trap of its own. A user interface is never the right answer in a design interview. If you catch yourself reaching for "build a UI," you've misread what the round is testing.
The scope question is doing more work than it looks like. It's really asking you to draw the line around what the system must do, before anyone talks about how well it needs to do it.
Not Knowing Something Isn't a Reason to Dodge It
There's a quieter mistake here: steering every question toward whichever option you already know, hoping the interviewer never asks about the other one.
The interviewer is a working engineer, not a teacher grading effort, and they will notice the dodge. If you don't know how to build an API, go learn it before the interview. Don't architect your questions around avoiding it.
Sound Like You're in the Room, Not Reading From a Card
Everything above can be technically correct and still land badly, because delivery is doing more work than most candidates realize.
Imagine two versions of the same candidate asking the exact same three questions. One sounds like they're reciting a checklist, pausing stiffly after each answer before moving to the next line. The other sounds like they're actually talking to a product manager, reacting to what they just heard before asking the next thing.
The content is identical. The impression is not.
A design interview is a conversation you're steering, not a form you're filling out. The moment it stops sounding like the first thing, the interviewer starts wondering how you'll actually behave on a team.
Getting the opening right buys you something real: a shared picture of the system before you start pulling it apart. That's exactly where BookMyShow's requirements actually begin, once you know what to ask about a movie theatre before you ever ask about a seat.
The Essentials
- State the business objective in one sentence before asking anything else. It aligns you and the interviewer on what the system is, separate from how it works.
- A requirements-sounding overview is still a mistake, even if you know the system. Naming features early skips the alignment step the interviewer actually needs.
- Scope, interface, and persistence are the three questions that follow alignment. A user interface is never a valid answer to the interface question.
- Not knowing something is a gap to close, not a question to avoid. Steering every question away from a weak spot reads as evasion, not strategy.
- Delivery changes how correct answers land. The same three questions sound completely different depending on whether they're recited or actually asked.