Why this matters: the meeting-room scheduler looks like the friendliest problem on the list — everyone has booked a room, everyone thinks they know the requirements. That familiarity is the trap. The design hinges on one precise question almost nobody thinks to ask: what exactly counts as a conflict? Candidates who assume the answer build systems where back-to-back meetings collide; candidates who ask it out loud have already won the first act.

The prompt, as given

Design a meeting-room booking system for an office.

The building has rooms; people need them for meetings. Your system decides what's available, takes bookings, helps people find a room that fits, and keeps two meetings from colliding in the same room.

Rooms, bookings, availability, conflicts. Every noun feels obvious — which is exactly why the scoping conversation matters more here, not less. The interviewer has precise semantics in mind for each of those words, and "obvious" is where wrong assumptions hide.

The questions, and why each one matters

"What counts as a clash — does a meeting ending at 11:00 conflict with one starting at 11:00?" This is the round's quiet centerpiece. If intervals are treated as closed, every back-to-back pair of meetings — the single most common booking pattern in any office — reads as a conflict, and your system fails at the thing offices do all day. The answer you want to hear (and the representative one below) is half-open intervals: a booking owns [start, end), so 10:00–11:00 and 11:00–12:00 touch but never overlap. Asking this question unprompted is the strongest single signal you can send in this problem, because it shows you know that conflict logic is semantics first, code second.

"What does a booking carry?" Organizer, attendee count, equipment needs, times. The follow-up that matters: do we track attendee identities? If the answer is "only the count," your capacity check is an integer comparison and the model stays small. Asking keeps you from building a people-directory nobody asked for.

"Do users pick a room, or does the system suggest one?" Both, typically — and "both" is a design fork: direct booking needs a conflict check for one room, suggestion needs a search across rooms that filters (capacity, equipment) and then ranks. Asking how the suggestion should rank — smallest fitting room? nearest? — tells you whether ranking is fixed or a policy that will change.

"How do cancellations behave?" Cancel any time before start, slot frees immediately. This sounds administrative but it shapes structure: a cancelled booking must genuinely leave the conflict-checking data, not linger as a flag every check has to remember to skip.

"What's the scale, and what's the hot path?" Hundreds of rooms, thousands of bookings per room per year — and availability checks dominate. That last fact is a design instruction in disguise: conflict checking must be better than a scan over everything.

"What's out of scope?" Notifications, calendar rendering, cross-office booking, persistence. Volunteer the boundary and say where each would attach.

The requirement set this chapter builds against

Rooms         one building, fixed capacity + equipment
              (screen, VC, whiteboard) per room
Booking       organizer, attendee COUNT, needed equipment,
              start + end time
Conflict      half-open intervals: [10:00,11:00) and
              [11:00,12:00) do NOT clash
Finding       user picks a room, OR system suggests:
              filter by capacity+equipment, rank smallest-fit
Cancellation  any time before start; slot frees immediately
Scale         hundreds of rooms; thousands of bookings
              per room per year; availability is the hot path
Out of scope  attendee identities, notifications,
              cross-office, persistence

The design pressure is all latent in this table: half-open semantics will become a one-line comparison that must live in exactly one place; the hot-path fact will push bookings into an ordered structure so conflicts are neighbor checks; and "suggest a room" will separate into a filter stage that's fixed and a ranking stage that's a policy.

As with every chapter in this course: a live interviewer's answers may differ — maybe their office wants closed intervals with mandatory gaps, or approval steps for big rooms. The skill is the conversation; a different answer sheet just steers the same method to a slightly different design.