Walk the Building Before You List a Single Feature

Once you have that shared picture, the next question is what to ask about a movie theatre before you ever ask about a seat.

Most candidates get this part wrong in a way that's easy to miss, because every individual question they ask still sounds reasonable on its own.

The Mistake: Asking Whatever Comes to Mind

Picture a handful of candidates each proposing one requirement for BookMyShow. One asks about movie listings. Another asks whether users need to register before booking. 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, makes you look like you're free-associating instead of working through a system.

So the real skill isn't coming up with good questions. It's having a fixed starting point that produces the questions in the right order every time, regardless of 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. Software design fundamentally means identifying the objects a system is built from, and a real-world system's physical layout already hands you most of those objects in the right order, before you've thought about a single use case. City, Theatre, Auditorium, Seat, and Movie aren't just 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 BookMyShow only handle movies, or does it also cover live events like stand-up comedy, the way the real platform eventually did? For a first pass at this design, the answer is to explicitly narrow scope: movies only, no events. Naming that boundary yourself, instead of waiting to be asked, shows you understand that 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, popcorn add-ons, and similar extras are real features of the actual product, but they're not what an interviewer is measuring, 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.

Notice what didn't happen here: no jumping to pricing, no jumping to user accounts. Each question is the natural next layer of the same structure, and that's exactly what makes the sequence easy for an interviewer to follow.

The seat itself is still a few layers away. Before you get there, there's one more entity worth a closer look: what a "seat" actually needs to represent once different theatres start naming and pricing them differently.

The Essentials

1. Order matters more than the individual question. A technically correct question asked at a random point in the conversation still reads as scattered.
2. Map the real physical structure before asking about use cases. For BookMyShow, that's city, then theatre, then auditorium, then seats and the movie playing in it.
3. The physical structure is the entity list. Each layer of a real-world system's structure tends to become an actual class in the design.
4. State scope decisions instead of just asking about them. Narrowing to "movies only, no events" is a decision worth naming, not a detail to leave open.
5. Five to eight core features, then stop. Extras like food ordering come after the core booking flow is fully worked out, not alongside it.