Walk the Building Before You List a Single Feature

You've stated the business objective and the interviewer has confirmed it. Now you have to decide what to ask about a movie theatre before you ever ask about a seat.

Most candidates get this wrong, but it's easy to miss why: each individual question still sounds reasonable on its own.

The Mistake: Asking Whatever Comes to Mind

Picture a handful of candidates each proposing one requirement for BookMyShow:

1. One asks about movie listings.
2. Another asks whether users need to register before booking.
3. A third asks about dynamic pricing based on showtime.

Every single one of those is a fair question. The problem is the order, not the content. Jumping from booking to registration to pricing, with no structure connecting them, reads as free-association, not design.

So the real skill isn't coming up with good questions. It's having one starting point that gives you the right order of questions every time, no matter which system you're asked to design.

The Technique: Map the Physical Structure First

Here's that starting point. Before asking about any use case, describe the real, physical version of the system you're designing.

For BookMyShow, that means asking yourself what's actually sitting inside a movie theatre in the real world, layer by layer:

1. A city contains multiple theatres.
2. A theatre contains multiple auditoriums, because a single theatre building can screen several different movies at once.
3. An auditorium contains a set of seats, and it hosts one movie or show at a time.

ExpandCity contains theatres, a theatre contains auditoriums, and an auditorium contains both seats and the movie or show playing in it

This hierarchy isn't just a warm-up exercise. It's the entity list. At its core, software design means finding the objects a system is built from, and the real-world physical layout gives you most of them already, in the right order. City, Theatre, Auditorium, Seat, and Movie aren't concepts you're brainstorming — they're the actual classes this system will need.

Decide the Boundary, Don't Just Ask About It

Walking the physical structure surfaces scoping questions too, and some of them are worth deciding out loud rather than leaving open.

One example: does this handle only movies, or events too, the way the real platform eventually added? For this pass, narrow it explicitly: movies only, no events. Naming that boundary yourself, instead of waiting to be asked, shows you understand scope is a decision, not a detail to figure out later.

Core Features First, Everything Else Later

The physical structure gives you entities. It doesn't yet tell you which use cases matter most, and that's where a second discipline kicks in.

In a machine coding or LLD round, aim for five to eight core features before you go anywhere near the smaller ones. For BookMyShow, the core feature is booking a movie ticket. Food ordering and popcorn add-ons are real features of the actual product, but an interviewer isn't measuring them, and pulling them in early just burns time you need for the core flow.

Turning the Structure Into an Actual Question Sequence

With the physical structure in hand, the requirement questions almost write themselves, because each one sits at the next level down from the one before it:

1. Does the system need to support multiple cities? Yes. Before picking a movie, a user has to pick which city they're booking in.
2. Within a chosen city, can a user see which movies are playing? Yes. Once a city is selected, the next thing a user needs is a list of movies currently showing there.
3. For a chosen movie, can a user see which theatres are showing it and at what times? Yes. That's the next layer down: movie leads to theatre and showtime, not straight to a seat.

None of these questions jump to pricing or user accounts. Each one is the next layer of the same structure, which is exactly what makes the sequence easy for an interviewer to follow.

That sequence also tells you when to stop asking "can there be more than one" at a given layer, and when a question like that is actually worth your interviewer's time.