Machine coding round
Hotel Room Booking System Coding Interview Problem
What this interview round tests
The hotel room booking system is a low-level design staple — the Booking.com / Airbnb-style round that shows up constantly for SDE1 and SDE2 backend roles. It reads like CRUD, but almost nobody gets full marks, because the grading lives in date arithmetic: two stays conflict only when their date ranges truly overlap, and a guest checking out on the 10th must not block a guest checking in on the 10th.
Interviewers keep asking it because date-range overlap is a real production skill. Calendars, rentals, appointments, and room inventory all hinge on the same predicate, and an off-by-one at an interval boundary is exactly the kind of bug that ships to production and surfaces as a double-booked room. The round also folds in classic booking mechanics: validation, cancellation that releases every night it held, and availability queries that stay consistent as bookings mutate state.
The scenario
You are handed a backend repository for a hotel booking service. Creating bookings, cancelling them, and querying room availability all exist — but the date logic is wrong in ways the bundled test suite exposes immediately.
Overlapping stays for the same room are accepted, back-to-back stays that should be legal get rejected, invalid ranges (check-out on or before check-in, bookings for unknown rooms) slip through, and cancelling a booking does not reliably free its dates for the next guest. Your job is to fix the service layer until every test goes green.
What you’ll practice
- Date-range overlap: the half-open [check-in, check-out) interval predicate done correctly
- Boundary cases: same-day turnover, identical ranges, and fully-contained stays
- Input validation: rejecting inverted ranges, unknown rooms, and malformed requests
- Cancellation semantics: releasing every night a booking held, and only those
- Availability queries that stay consistent while bookings are created and cancelled
- Deterministic listings so clients (and tests) always see stable ordering
How to approach it
Nail the overlap predicate first and put it in exactly one place: two half-open intervals [a, b) and [c, d) overlap when a < d and c < b. Treating check-out day as exclusive is what makes same-day turnover legal — most failed attempts either double-book a boundary night or reject a perfectly valid back-to-back stay.
Then structure each operation as validate-first: check the range shape, the room, and every conflicting booking before mutating anything, so a rejected request leaves state untouched. Cancellation is the inverse — verify the booking exists and is active, then release its dates so a follow-up availability query reflects reality immediately.
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 Airbnb / Booking.com LLD interview question?
It covers the same core: room inventory, date-range conflict detection, booking lifecycle, and availability queries. Instead of sketching classes on a whiteboard, you fix a real service layer against a bundled test suite — which is how machine coding rounds are actually graded.
Why do half-open intervals matter so much here?
Because hotel nights are half-open by nature: a stay occupies check-in through the night before check-out. Model that as [check-in, check-out) and same-day turnover works automatically; model it as closed dates and you either double-book boundaries or reject legal stays. Interviewers probe exactly this.
Do I need to set anything up to try it?
No. Open the problem to read the full brief with no signup, then solve it in the browser workspace or download the starter repo and run the bundled verify script locally in Java, Python, or C++.