</>
Vizly

Meeting Rooms — The Solo Receptionist

July 16, 20266 min
DSAIntervalsBeginner

Dungeon 13, Boss 4. One receptionist, one calendar, one honest question: can a single human attend every meeting? Sort by start, check each neighbor, done. The easiest boss in the dungeon, and the setup for the room-count crunch.

Boss 4: The Solo Receptionist

Boss 3 fixed a broken schedule by cancelling acts. This boss stands one step earlier in the pipeline and asks something humbler: was the schedule ever fixable at all? No cancellations, no merging, no counting. Just yes or no. It is the easiest boss in the dungeon, deliberately, because what it installs is a lens, not a machine: after sorting by start time, only neighbors can conflict first. Once that clicks, a whole family of interval problems collapses into one-pass scans.


The story

A small office has exactly one receptionist, and management, in its wisdom, wants them to personally sit in on every meeting of the day. Today's calendar: [[0, 30], [5, 10], [15, 20]]. Minutes since 9am, say.

Before saying yes to the boss, the receptionist asks the only question that matters: can one human actually do this?

Draw the day:

minute    0    5    10   15   20   25   30
[0,30]    ██████████████████████████████
[5,10]         ██████
[15,20]                  ██████

The [0,30] meeting swallows the other two whole. At minute 5 the receptionist is needed in two rooms at once, and cloning is not in the job description.

Answer: no, this schedule is impossible.

House rule for this room: back-to-back is fine. A meeting ending at 10 and another starting at 10 is a brisk walk down the hallway, not a conflict. Endpoints touching don't count.


The problem, dressed up properly

Given an array of meeting time intervals where intervals[i] = [start_i, end_i], determine if a person could attend all meetings.

LeetCode 252. It sits behind LeetCode's premium wall, but the identical problem is free on LintCode and on NeetCode as "Meeting Schedule".


The naive attempt

A conflict is any two meetings that overlap, so check every pair with the overlap test from Boss 1:

def can_attend_meetings(intervals):
    n = len(intervals)
    for i in range(n):
        for j in range(i + 1, n):
            a, b = intervals[i], intervals[j]
            if a[0] < b[1] and b[0] < a[1]:   # Boss 1's overlap test
                return False
    return True

Correct, O(n²), and honestly not tragic for a day's calendar. But it interrogates every pair of meetings, including pairs hours apart that could never touch. All that work to answer a question the sorted order answers by itself.


The weapon: sort by start, check the neighbors

Sort the meetings by start time. Now here's the insight that makes the pair-checking pointless: if any two meetings overlap, then some adjacent pair in sorted order overlaps too.

Why? Say a meeting conflicts with some earlier, non-adjacent meeting. That earlier meeting runs so long it reaches past the current one's start. But then it also reaches past every meeting between them, because those all start even sooner. The conflict shows up between neighbors before it shows up anywhere else. So scanning neighbors catches everything, and the scan is one line: does this meeting start before the previous one ends?

def can_attend_meetings(intervals: list[list[int]]) -> bool:
    intervals.sort(key=lambda m: m[0])            # by start time
    for i in range(1, len(intervals)):
        if intervals[i][0] < intervals[i - 1][1]:  # starts before prev ends
            return False                           # two rooms, one human
    return True

That's it. That's the boss. After three dungeons of heaps, DP tables, and greedy proofs, the lesson is knowing when none of that is needed, because sorted adjacency already answers the question.


Watching it work

The receptionist's calendar, sorted by start: [0,30], [5,10], [15,20].

pair [0,30] vs [5,10]:   5 < 30   conflict → False

One comparison and the day is officially impossible. For the happy path, try [[5,8], [8,10], [11,12]]:

pair [5,8]  vs [8,10]:   8 ≥ 8    fine (back-to-back)
pair [8,10] vs [11,12]:  11 ≥ 10  fine
end of pairs → True ✓

Note the 8 ≥ 8 case sailing through: the endpoint-touch convention, honored in code by using a strict comparison for the conflict.

Recognizing sorted adjacency in the wild

The tell is a question about any pair: does any pair conflict, what's the closest pair, does any value repeat. Sorting turns "any pair" into "any neighbor", shrinking n² checks into n. Duplicate detection, minimum gap between numbers, and this boss are all the same move. When a pair-question feels quadratic, ask what sorted order would put next to each other.


Gotchas

1. Skipping the sort. On unsorted input, neighbor-checking is meaningless: [[15,20], [0,30], [5,10]] has quiet neighbors and a screaming conflict. The insight is "only neighbors conflict first after sorting by start". The sort is not optional seasoning.

2. Flagging back-to-back as a clash. The conflict test must be strict: cur starts before prev ends. Write "or equal" into it and [5,10] followed by [10,15] fails a perfectly walkable day. Endpoint conventions flip between bosses in this dungeon, so check the fine print every time.

3. Comparing against the wrong end. After sorting by start, the previous meeting is the only one that matters for the first conflict. But swap the check to compare starts against starts, or ends against ends, and overlapping meetings slide through. The question is always: did the last meeting finish before this one begins?

4. Overselling the answer. This scan says yes or no for one attendee. It does not say how many meetings collide at once, or how many receptionists the day would take. The moment the question becomes "how many rooms", you're in Boss 5's arena, and this little check alone won't survive there.


Complexity

The scan is a single O(n) pass, so the sort is the whole bill, and it's honest to say so out loud in an interview.

Time: O(n log n). Space: O(1).


Boss down. XP gained.

The receptionist walks back to management with a printout and a straight face: minute 5, two rooms, one body. The meeting about the meetings is rescheduled.

What you walked away with:

  • After sorting by start, only neighbors can conflict first, so one pass answers the any-pair question
  • Feasibility questions ("can one person / one machine do all of this?") are sort-plus-scan, no machinery required
  • Strict versus non-strict comparisons carry the endpoint convention, one character of code, whole different answer
  • Honest complexity talk: the scan is linear, the sort dominates, say which part costs what

Next up: Boss 5 — The Conference Crunch. Same building, crueler question: management no longer asks whether the day fits, they demand every meeting happens, so how many rooms does the day actually need? The neighbor check shatters, and a heap from Dungeon 10 walks back through the door.

Edit this page on GitHub