Meeting Scheduler

Calendar-Based Meeting Coordination

Design a meeting scheduler that finds common free time across people in different time zones, books them and a suitable room in one atomic step, and handles replies and cancellations.

Overview

A meeting scheduler answers two questions. When are all these people free for an hour? And can I book that hour for all of them and a room with a screen, right now, without someone else grabbing it first? The first is an interval problem. The second is a concurrency problem, because one booking touches several calendars at once.

The interviewer listens for four things: a clean interval model (every time stored in UTC, working hours converted from each person's zone), a free-slot algorithm you can state and give a cost for, a booking that locks several calendars without deadlocking, and sensible behavior for replies, cancellations and recurring meetings.

Scoping the problem

Are attendees in different time zones? — Working hours must be converted per person and per date — Yes
Only working hours, or any time? — Sets the search window — Working hours, per person
Rooms: capacity, equipment? — Adds a second resource to book with the people — Yes: seats and a video screen
What if a room and people are free but a second booking arrives at the same time? — Booking must be atomic across calendars — One of them wins; the other gets a clear error
Does a declined invite free the person's time? — Changes their availability — Yes
Recurring meetings? — Store a rule or every instance — A rule, expanded on demand (follow-up)
Notifications? — Who is told what, and when — Invite and cancel events to a listener

Time zones: store UTC, convert working hours

Every interval in the code is a timezone-aware datetime in UTC. A person's working hours are local ('9 to 5 in New York'), so they are converted to UTC for each date asked about. The date matters because of daylight saving time: the US moves its clocks on the second Sunday of March and the UK on the last Sunday of March, so for about three weeks the gap between the two is one hour smaller.

March 6 — 14:00 to 22:00 — 09:00 to 17:00 — 14:00 to 17:00
March 10 (US on summer time, UK not yet) — 13:00 to 21:00 — 09:00 to 17:00 — 13:00 to 17:00
March 30 (both on summer time) — 13:00 to 21:00 — 08:00 to 16:00 — 13:00 to 16:00

A fixed offset such as 'New York is UTC-5' would be wrong for most of the year. Use the zone name (America/New_York) and let the time zone database do the conversion.

Finding common free time

The code puts everyone's busy intervals into one list, sorts it by start time, and sweeps it once inside the common working window. Any gap at least as long as the meeting is a candidate.

The demo's trace on March 10, 2026, for Ana (New York), Bo and Cy (London), looking for 60 minutes:

start — window is 13:00 to 17:00 — 13:00 — 13:00
1 — Bo 13:00 to 14:00 — 13:00 — none — 14:00
2 — Cy 13:00 to 14:00 (same 1:1) — 14:00 — none — 14:00
3 — Cy 15:30 to 16:00 — 14:00 — 14:00 to 15:30 — 16:00
end — window closes at 17:00 — 16:00 — 16:00 to 17:00

With B busy intervals across all attendees, the cost is O(B log B) for the sort and O(B) for the sweep.

Booking: many locks, one order

A meeting occupies several schedules at once: every attendee's and one room's. The check (all free?) and the write (add to all) must be one atomic step, or two organizers can both see a free slot and both book it. The code takes every schedule's lock before checking, and always in the same order, sorted by owner id. If one booking locked Ana then Bo while another locked Bo then Ana, each could wait on the other forever; a single global order makes that impossible.

Rooms are tried smallest first among those with enough seats and the right equipment, so a three-person call does not take the eight-seat room. Invitations go out after the locks are released, so a slow listener never holds up other bookings.

What you will be able to do

Store every time in UTC and convert working hours per person and per date, including daylight saving changes.
Find common free slots with one sorted sweep and state its cost.
Book several calendars and a room atomically, and explain how a fixed lock order prevents deadlock.
Handle replies (a decline frees the time) and cancellations, and notify the right people.
Store recurring meetings as a rule and expand them in the organizer's zone.

Functional requirements

free_slots(people, day, minutes) returns every gap of at least that length inside everyone's working hours
book(title, organizer, attendees, start, minutes, needs) books all people and the smallest suitable free room, or fails with SlotTaken or NoRoom
Rooms have a capacity and a set of equipment; a booking needs enough seats and every item asked for
respond(meeting, person, answer): accepted, declined or pending; a decline frees the person's time
cancel(meeting) frees every attendee and the room and notifies attendees
People work in their own time zones; all times are stored in UTC

Non-functional requirements

Two bookings that share a person or a room never both succeed for overlapping times
No deadlock: locks are always taken in one global order
Free-slot search is O(B log B) in the number of busy intervals
Correct across daylight saving changes: zone names, not fixed offsets
Notification channels are pluggable listeners; the scheduler does not know about email

Interview questions

Your first version intersected calendars two at a time. Is the sweep better?
How do you avoid deadlock when a booking locks several calendars?
How do you store a weekly meeting that runs for a year?
There is no slot where everyone is free. What does the scheduler offer?