Conference Room Booking System
Design a conference room booking system — room setup, conflict-free time-slot booking, cancellation, and recurring-meeting bonus features.
Design and implement a conference room booking system for an office. The system should let admins register meeting rooms, let employees book a room for a specific time slot, and correctly prevent double-booking — while handling the edge cases that come with real calendars: back-to-back meetings, cancellations, and capacity limits.
You described the original question only at a high level — "various features and edge cases were given" without listing them. This is a constructed, representative version of that kind of problem, built to match the shape of a real conference-room-booking machine coding round. Swap in your actual requirements and edge cases if they differ.
This one tests whether you can enforce a no-overlap invariant correctly — two bookings for the same room can never share any overlapping time, including the exact boundary case where one meeting ends the instant another begins — while keeping room, booking, and user concerns cleanly separated.
Objective
The primary objective of this project is to design and implement an in-memory conference room booking system with proper class-level OOP design, where rooms can be registered with a capacity, employees can book and cancel time slots without ever double-booking a room, and the system correctly rejects invalid or conflicting requests with clear errors.
Functional Requirements
Requirements are split into two tiers so you know what to prioritize under time pressure: build first, and build for bonus points if time allows.
Part 1 — Basic Requirements
Core functionality you must build and get working first.
1. Room Management
2. Booking a Room
3. Cancellation & Lookup
Two employees attempting to book the same room for overlapping times at the same instant must not both succeed — exactly one booking should win, and the design should be thread-safe under concurrent booking attempts on the same room.
Part 2 — Bonus Features
Extensibility checks — can your design support recurring meetings, prioritization, and notifications without a rewrite of the core booking logic.
Example Usage: Full Walkthrough
1. Register rooms
> addRoom("r1", "Falcon", capacity: 8)
> addRoom("r2", "Griffin", capacity: 4)
✅ 2 rooms registered.
2. Book a room for a valid slot
> bookRoom("r1", "alice", "2026-09-15T10:00", "2026-09-15T11:00", attendeeCount: 5)
✅ Booking b1 confirmed. Room: Falcon, 10:00–11:00.
3. Attempt an overlapping booking — rejected
> bookRoom("r1", "bob", "2026-09-15T10:30", "2026-09-15T11:30", attendeeCount: 3)
❌ Room Falcon is already booked from 10:00–11:00 on 2026-09-15. Slot unavailable.
4. A back-to-back booking is allowed
> bookRoom("r1", "bob", "2026-09-15T11:00", "2026-09-15T12:00", attendeeCount: 3)
✅ Booking b2 confirmed. Room: Falcon, 11:00–12:00.
5. A booking that exceeds capacity is rejected
> bookRoom("r2", "carla", "2026-09-15T14:00", "2026-09-15T15:00", attendeeCount: 6)
❌ Griffin's capacity is 4 — cannot accommodate 6 attendees.
6. Cancel a booking, freeing the slot
> cancelBooking("b1")
✅ Booking b1 cancelled. Falcon is now free from 10:00–11:00 on 2026-09-15.
7. Find available rooms for a new request
> findAvailableRooms("2026-09-15T10:00", "2026-09-15T11:00", minCapacity: 4)
📋 Available: Falcon (capacity 8), Griffin (capacity 4)
Bob's first attempt correctly fails against Alice's existing booking, but a back-to-back booking starting exactly when hers would have ended succeeds — showing the overlap check treats touching boundaries as non-conflicting. Cancelling Alice's booking immediately reopens that slot for the availability search.
Expectations
Full, working code with proper class-level design — not a single script — and legible code throughout. Bonus points are awarded for tackling the optional/bonus features above, but only after the core booking and conflict-prevention logic is complete and correct.