Meeting Scheduler — OOD Interview Walkthrough

Phase 1: Requirements & Use Cases

Interviewer: "Design a meeting scheduler — something like Google Calendar or Outlook's meeting booking feature."

Candidate: "Sure. Let me restate to confirm scope. I'm imagining a system that lets users schedule meetings, invite attendees, book a room, and detect conflicts — all modeled at the class level. No distributed infrastructure, no database schema. Does that match what you're looking for?"

Interviewer: "Yes. Who are the actors?"

Candidate: "I see three main actors: a User (who can organize or attend meetings), a MeetingRoom (a bookable resource), and a MeetingScheduler (the orchestrating service). Let me list the core use cases:

1. Create a meeting with a time slot, attendees, and an optional room
2. Detect conflicts — both for the room and for individual attendees' calendars
3. Send notifications when a meeting is created, updated, or cancelled
4. Accept or decline an invitation (RSVP)
5. Cancel a meeting and notify all attendees
6. Support recurring meetings"

Interviewer: "What about external attendees — people outside the company?"

Candidate: "I'll treat all attendees as Users in the system for V1. External guest support would require a separate identity model — email-only attendees with no calendar integration — which adds significant complexity. I'd scope that out."

WHY: External attendees break the assumption that every attendee has a local Calendar. Supporting them requires a two-track model and is a distraction from the core OOD patterns being tested.

Interviewer: "Do you need to persist meetings across restarts?"

Candidate: "I'll assume in-memory storage for this design. Persistence is an…