Machine coding round
Seat Reservation System Coding Interview Problem
What this interview round tests
Seat reservation — the BookMyShow / ticketing-style booking system — is one of the most frequently asked machine coding rounds for SDE1 and SDE2 backend roles. It looks simple on the whiteboard, but the grading happens in the details: seats that must exist and belong to the right event, reservations only from AVAILABLE state, cancellations that release every held seat, and listings that come back in a deterministic order every time.
Interviewers pick it because it maps directly onto real backend work: enforcing a state machine across entities, validating input against ownership rules, and keeping reads consistent while writes mutate state.
The scenario
You are handed a backend repository for an event seat reservation service. Reserving seats, cancelling reservations, and listing availability all exist — but they are incomplete and partially broken.
Requests can sneak duplicate seat ids through, seats from the wrong event get reserved, non-AVAILABLE seats can be double-booked, and users can cancel reservations they don’t own without every seat returning to AVAILABLE. The bundled test suite fails on the starter code; your job is to fix the service layer until it goes green.
What you’ll practice
- Reservation state machines: AVAILABLE → RESERVED transitions with no illegal paths
- Input validation: de-duplicating seat ids per request, rejecting unknown seats
- Cross-entity integrity: every seat must exist and belong to the event being booked
- Ownership rules: a user can cancel only their own active reservation
- Releasing state atomically: cancellation returns every held seat to AVAILABLE
- Deterministic listings so clients (and tests) always see stable ordering
How to approach it
Start from the failing tests — they encode the contract. Trace one reservation end-to-end: validate the request (unique seat ids, seats exist, seats belong to the event, all AVAILABLE), then transition every seat and create the reservation as one consistent step so a partial failure can’t leave seats half-held.
Cancellation is the mirror image: verify the caller owns an active reservation, flip its state, and return each seat to AVAILABLE. For listings, sort explicitly rather than relying on map/dict iteration order — deterministic output is part of the spec, not a nicety.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
Is this the same as the BookMyShow interview question?
It covers the same core: seat inventory, reservation state transitions, ownership, and consistent availability listings. Instead of designing it on a whiteboard, you fix a real service layer against a bundled test suite — which is how the round is actually graded in machine coding interviews.
What do interviewers look for in a seat reservation round?
Correct state transitions under every edge case: duplicate seats in one request, seats from another event, double-booking a held seat, and cancellations that must release everything. Clean validation-first structure in the service layer matters as much as passing tests.
Do I need to set anything up to try it?
No. Open it in the browser workspace to edit and run the tests with zero setup, or download the starter repo and run the bundled verify script locally in Java, Python, or C++.