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 write a single requirement or sketch a single class, you need to say one sentence to the interviewer first.
Skip it, and everything you say for the rest of the interview sounds like a script instead of a conversation.
Know the System, or Say So
The first real decision in any design interview: do you actually know this system, or not? If not, ask. If yes, don't ask anyway.
Asking anyway wastes the interviewer's time. It also shows you can't lead a conversation on your own.
The Wrong First Sentence
Knowing the system isn't enough on its own. The wrong opening sentence undoes it 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.
State the Business Objective, Then Wait
Say the business objective as one plain sentence, like the good example above. Then wait for the interviewer to confirm it before you ask anything else. This sentence should skip cities, seat counts, and databases entirely. Its only job is to make sure both of you agree on what the product is, before either of you talks about how it works.
This is also the first thing you show the interviewer: that you can describe a system in one sentence instead of listing too many details at once.
The Three Questions That Follow
Only after the interviewer confirms the objective do the real clarifying questions start. These three questions stay the same no matter which system you are asked to design:
- 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?
A user interface is never the right answer to the interface question. Saying "I'll build a UI" means you have misunderstood what this interview is testing.
The scope question matters more than it seems. It decides what the system must do, before anyone talks about how well it should do it.
Don't Dodge What You Don't Know
Some candidates only ask about the option they already know, and avoid the one they don't. Interviewers notice this immediately.
Delivery Matters as Much as Content
The same three questions land differently depending on how you ask them.
Reciting a checklist — each question ignores the answer before it, like reading down a form:
You: Should I model just entities, or the full system?
Interviewer: (answers)
You: Okay. Should this expose an API or take command-line input?
Interviewer: (answers)
You: Got it. Real database or in-memory?
Reacting to what you just heard — each question builds on the last one, the way an actual conversation moves:
You: Should I model just entities, or the full system?
Interviewer: Full system.
You: Got it, so bookings and payments too — that means I'll need an API surface rather than a CLI, right? And should that connect to a real database, or is in-memory fine for now?
The content is identical. The impression is not.
Getting the opening right gives both of you the same picture of the system, before you start breaking it into parts. That is exactly where BookMyShow's requirements begin — you first ask about a movie theatre, and only then about a seat.
Keep reading