Requirements checklist

□ Conflict semantics — ask unprompted: half-open [start,end),
  back-to-back meetings never clash (the round's key question)
□ Booking shape: organizer, attendee COUNT (no identities),
  equipment, start+end
□ Finding: direct pick AND system suggestion (filter -> rank,
  smallest-fit default)
□ Cancellation: any time before start, slot frees immediately
□ Scale: hundreds of rooms, thousands of bookings/room/year —
  availability checks are the hot path
□ Out of scope: notifications, calendar UI, cross-office,
  persistence

The core model

TimeSlot(start, end)     half-open; overlaps() defined ONCE here:
                         a.start < b.end && b.start < a.end
RoomCalendar (per room)  TreeMap start -> Booking, never overlapping
                         isFree = floor + ceiling neighbor check
Scheduler                book/cancel through calendar;
                         bookingsById for cancel lookup
Finder                   filter (capacity, equipment, isFree)
                         -> RankingStrategy (smallest-fit)
cancel                   REMOVES from the map — no cancelled flag

Principles demonstrated (name them at the decision)

• Separation of concerns — overlap math lives on the interval type, written once; no call site hand-rolls a comparison.
• Single responsibility — RoomCalendar is the only availability authority; booking, suggestion, and cancellation all go through it.
• Open/closed with judgment — ranking is a strategy seam because preference changes; the capacity/equipment filter is plain code because requirements don't.
• Invariant by construction — the calendar never holds two overlapping bookings, because every insert passes the neighbor check first.

Complexity facts

isFree          O(log n) — two TreeMap probes (floor, ceiling)
book / cancel   O(log n) + hash-map ops
suggest         O(R log n) over R candidate rooms
the argument    only start-order neighbors can clash, because
                the map never contains overlaps

What earns points, per report dimension

• Requirements & interface — asked the overlap question unprompted; pinned booking shape, both finding modes, and the hot-path scale fact before designing.
• Core design & invariants — half-open semantics said out loud on the type; ordered-by-start structure justified by the neighbor argument; one availability authority; cancellation as removal.
• Extension probe — place the new requirement on an existing seam (filter pipeline, booking state, presentation edge) and say which invariants are untouched.
• Complexity honesty — every O() with its because; never call the scan version "fine" without the n it's fine at.
• Communication — the floor/ceiling reasoning narrated while writing it, and rejected alternatives (global timeline, gap tracking) named with reasons.

Ready? Sit the live mock → — the interviewer will run a twist this chapter deliberately hasn't shown you.