Design a Meeting Scheduler

The Problem

Your company runs a 200-person engineering org across three offices. Scheduling a meeting is a daily nightmare: someone books a room, forgets to check participant calendars, and three people reply "I have a conflict." The organizer spends 15 minutes shuffling time slots, pinging Slack, and re-booking rooms. Multiply that by 40 meetings a day and you are burning hours on logistics.

A meeting scheduler like Google Calendar or Outlook solves this. It manages individual calendars, detects conflicts before they happen, books rooms with the right capacity, and finds time slots where all participants are free. Recurring meetings follow rules (every Monday at 10am) without manual re-creation.

Design the core classes for a meeting scheduler that supports calendar management, conflict detection, room booking by capacity, participant RSVP tracking, recurring meetings, and availability search across multiple participants.

Requirements

Clarifying Questions

Before jumping into class design, ask questions to turn the vague prompt into a concrete specification. Cover four areas: core actions, error handling, boundaries, and future extensions.

You: "What is the core scheduling flow? Does the organizer pick a time and invite people, or does the system suggest a time?"

Interviewer: "Both. The organizer can create a meeting at a specific time, or ask the system to find available slots across a set of participants."

Two modes: explicit scheduling and availability search. The availability search is the more interesting algorithm.

You: "How should conflict detection work? Can a user have overlapping meetings, or is that strictly blocked?"

Interviewer: "Block double-booking by default. If two meetings overlap for the same user, reject the second one. But allow the organizer to force-book if they acknowledge the conflict."

Strict conflict detection with an override option. The interval overlap check (start1 < end2 AND start2 < end1) will be the core algorithm.

You: "Do meetings need rooms? Is room booking part of the core design?"

Interviewer: "Yes. Rooms have a name, location, and capacity. The system should find rooms that fit the participant count and are available at that time."

Room booking adds a second dimension to conflict detection: participant conflicts AND room conflicts.

You: "Should we support recurring meetings? If so, what recurrence patterns?"

Interviewer: "Yes. Daily, weekly, and monthly with either an end date or a max occurrence count."

Recurring meetings generate multiple instances from a single rule. We need a RecurrenceRule that expands into concrete time slots.

You: "When a meeting is created or updated, who gets notified?"

Interviewer: "All participants. Notify on invitations, updates, and cancellations. Participants respond ACCEPTED, DECLINED, or TENTATIVE."

Observer pattern for notifications. Participant responses track RSVP state.

You: "Do we need to handle time zones or all-day events?"

Interviewer: "Not in the core design. Mention time zones as an extension."

Good. We keep time representation simple for now.

You: "Are we handling persistence, or is this in-memory only?"

Interviewer: "In-memory only. Persistence is out of scope."

Perfect. You have now clarified scope and ruled out unnecessary complexity.

Final Requirements

Functional Requirements:

1. Users have personal calendars that store their meetings
2. Create, update, and cancel meetings with a title, time slot, participants, and optional room
3. Detect and reject time conflicts for participants (interval overlap algorithm)
4. Book rooms by capacity and availability for a given time slot
5. Support recurring meetings (daily, weekly, monthly) with end date or occurrence count
6. Find available time slots across a set of participants within a date range
7. Participants respond to meeting invitations (ACCEPTED, DECLINED, TENTATIVE)
8. Notify participants on meeting creation, updates, and cancellations

Non-Functional Requirements:

1. Conflict detection must be efficient (sorted intervals for fast lookup)
2. Extensible for new recurrence patterns, notification channels, and room features
3. Thread-safe for concurrent booking operations

Out of Scope:

• Time zone handling
• All-day events
• Persistence / database
• UI rendering
• Calendar sync (CalDAV/iCal)

Example Inputs and Outputs

Scenario 1: Simple Meeting Creation

• Input: Alice creates "Sprint Planning" from 10:00-11:00, invites Bob and Carol, requests a room for 5
• Expected: System finds Room A (capacity 10), checks calendars for conflicts, books the meeting, sends invitations
• Why: Validates core scheduling flow (conflict check + room booking + notifications)

Scenario 2: Conflict Detection

• Input: Bob has "1:1 with Manager" from 10:30-11:30. Alice tries to schedule Bob for "Design Review" 10:00-11:00
• Expected: System detects overlap (10:00 < 11:30 AND 10:30 < 11:00), rejects the booking, returns conflict details
• Why: Validates interval overlap algorithm and error reporting

Scenario 3: Find Available Slots

• Input: Find a 60-min slot for Alice, Bob, Carol between 9:00-17:00. Alice busy 9:00-10:00 and 14:00-15:00. Bob busy 10:00-12:00. Carol busy 9:00-9:30
• Expected: Merged busy: [9:00-12:00, 14:00-15:00]. Gaps: 12:00-14:00 and 15:00-17:00
• Why: Validates interval merging and gap-finding algorithm

Try It Yourself

---

Step 1: Identify Core Entities

Start by asking: what are the main "things" in this problem? Look for nouns in your requirements: user, calendar, meeting, time slot, room, participant, recurrence rule, notification.

A common mistake is merging Calendar into User or putting room booking logic inside Meeting. Each class should have a single, clear job.

Notice we separated Calendar from User because they have different responsibilities. User is a data holder; Calendar manages the meeting collection and conflict detection. Merging them violates SRP.

Step 2: Define Relationships and Class Design

Class Diagram

Deriving the MeetingScheduler Interface

MeetingScheduler is the orchestrator. It coordinates between calendars, rooms, and notifications. No scheduling logic lives in Meeting itself.

Deriving state from requirements:

Deriving methods from needs:

Deriving the Calendar Interface

Calendar owns a user's meetings and handles conflict detection. This is where the interval overlap algorithm lives.

Deriving state from requirements:

Deriving methods from needs:

Key Relationship Decisions

Calendar owns Meetings (composition) because a meeting on Alice's calendar is a reference to the shared Meeting object, but the calendar manages its entries' lifecycle.

Meeting references Room (association) because a room exists independently. Cancelling a meeting releases the room, but the room continues to exist.

Participant wraps User (composition) because a Participant only makes sense for a specific meeting. It adds RSVP state to the User reference.

Step 3: Choose Design Patterns

Pattern: Observer, for meeting notifications

The signal: "Notify participants on creation, updates, and cancellations" with multiple event types and multiple listeners.