Section 1: The Room That Does Not Exist - Problem Understanding & Clarifications

Executive Summary: This section opens a Staff/Principal interview on a system everyone believes they already understand — a hotel booking engine — and shows how the first ten minutes govern the next fifty. We decompose the prompt four ways, name the two symmetric ways strong candidates fail it, and walk the five clarifying exchanges that each delete a category of work: room types rather than rooms, authorise-then-capture rather than stored cards, one property before 8,500, nights rather than dates, and the answer that separates hotel thinkers from shopping-cart thinkers — yes, we oversell, deliberately, within a tuned allowance. The prompt ends as five committed assumptions, each with the condition that would reverse it.

The interviewer does not hand you a leviathan. They hand you something you are sure you have seen before:

"Design the reservation system for a hotel. Start with one property — a 220-room beachfront hotel in Miami — where a guest searches dates, picks a room type, pays, and gets a confirmation number. Then tell me what has to change when we roll it out across Marriott: nine thousand properties, thirty brands, every country. Nobody may ever be sold a room that doesn't exist."

That last sentence is the bait, and recognition is the hook. "Booking system" fires a cached pattern — a rooms table, a row lock, decrement on purchase — close enough to correct that you can talk for forty minutes before the interviewer discovers you never examined it. Two symmetric failures live in that gap.

The Seat-Map Reflex. You model inventory as physical rooms — room 412, with its own row — and assign one at booking time. It works, and it is how nobody runs a hotel. 220 rooms x 365 dates is 80,300 lockable rows for one property and 547 million for the chain; worse, it stops the front desk shuffling guests, forbids free upgrades, and turns a counter decrement into bin packing. Signal recorded: modelled the physical world instead of the sellable product.

The Distributed-Transaction Maximalist. You hear "never oversell across nine thousand properties" and reach for global consensus, two-phase commit with the payment provider, a Kafka log as the book of record — a planetary consistency protocol for a workload peaking at 28 booking writes per second. Signal recorded: never did the arithmetic, so never discovered that the hard problem is search, not writes.

Key Insight: The prompt's one absolute — nobody may ever be sold a room that doesn't exist — is the sentence to interrogate, not to obey. Hotels oversell on purpose, every night, as policy. Accept that constraint at face value and you will spend an hour hardening the wrong invariant.

Decomposing the Prompt Four Ways

Map the territory before asking anything. Four dimensions, each changing what you build.

• What it does. Strip it to verbs: search availability, hold, pay, confirm, modify, cancel, check in. Seven operations, and only confirm can be wrong in a way that costs money.
• Who uses it. Not "users" — four audiences with conflicting needs. Guests want a price. The front desk assigns rooms and absorbs surprises at 11 p.m. Revenue managers reprice and set overbooking policy. OTAs and the GDS — Expedia, Booking.com, Amadeus, Sabre — hold their own copy of your availability and sell from it. Design for guests alone and you discover at minute fifty that you have no admin path.
• Why it exists. Commission. A direct booking is worth 15–25% more to the hotel than the identical booking through an OTA, because the OTA takes a cut of every one. That margin is the business case for building this at all, and it is why search quality is a revenue feature.
• How it is reached. Web, native app, a phone agent's console, an Expedia API push, and a travel agency's GDS terminal that speaks HTTP/1.1 and nothing more modern. The oldest consumer sets the floor for Section 4's contract.

Quick check before moving on: