Sorting

meetings = [[0,30], [5,10], [15,20]]

We never need to know WHICH meeting is in a room,
only HOW MANY rooms are busy at once.
So split each interval into two timeline events:

  starts = [ 0,  5, 15]   (a room is needed)
  ends   = [30, 10, 20]   (a room frees up)

A room is needed at every start and freed at every end. The peak number of simultaneously-busy rooms is the answer. Why this reframing is safe: overlap is purely a function of how many starts have happened before a given end — meeting identity is irrelevant. (Note: extracted in input order the ends are [30,10,20]; we sort them next.)

starts (sorted): [ 0,  5, 15]
ends   (sorted): [10, 20, 30]
                  ^         ^
                 si=0      ei=0

rooms = 0   (busy rooms right now)
max   = 0   (peak ever seen)

We sort starts and ends separately in ascending order (ends becomes [10, 20, 30]). Why this is safe: we are sweeping a timeline, so we only ever care about the next start vs the next end — not which end belongs to which start. Two pointers si and ei walk the two sorted lists in time order, and the loop runs only while si has starts left.

starts: [ 0,  5, 15]   ends: [10, 20, 30]
          ^                    ^
         si=0                 ei=0

starts[si]=0  vs  ends[ei]=10
0 < 10  -> a meeting STARTS first

rooms = 0 -> 1     si: 0 -> 1
max   = max(0,1) = 1

The earliest event in the whole timeline is the start at t=0 (since 0 < 10). A new meeting begins, so we allocate a room and advance si. Why safe: comparing the two pointer fronts always finds the globally next event, because both lists are sorted.

starts: [ 0,  5, 15]   ends: [10, 20, 30]
              ^              ^
             si=1           ei=0

starts[1]=5 < ends[0]=10  -> another meeting STARTS
before the soonest end (10) has passed.

rooms = 1 -> 2     si: 1 -> 2
max   = max(1,2) = 2

At t=5 a second meeting starts while the [0,30] meeting is still running and the earliest free time is 10 (5 < 10). They overlap, so we need a second room. Why safe: because ends is sorted, ends[ei]=10 is the earliest possible free time; if even that hasn't passed, no room is free.

starts: [ 0,  5, 15]   ends: [10, 20, 30]
                  ^          ^
                 si=2        ei=0

starts[2]=15  vs  ends[0]=10
15 >= 10  -> the next event is an END

rooms = 2 -> 1     ei: 0 -> 1
max   = max(2,1) = 2   (unchanged)

The next chronological event is now an end at t=10 (since 15 >= 10): the [5,10] meeting finishes before the next meeting starts. A room is released, so we advance ei (not si). Why safe: when the next start is not earlier than the soonest end, that room genuinely becomes reusable, so we decrement instead of allocating.

starts: [ 0,  5, 15]   ends: [10, 20, 30]
                  ^               ^
                 si=2            ei=1

starts[2]=15 < ends[1]=20  -> a meeting STARTS
A room freed at t=10, so we reuse it.

rooms = 1 -> 2     si: 2 -> 3 (all starts consumed)
max   = max(2,2) = 2

At t=15 the third meeting begins (15 < 20, the soonest remaining end). One room freed at t=10, so the running count goes 1 -> 2 — it does not exceed the previous peak. After advancing, si=3 reaches the end of starts, which is our loop stop condition. Why safe: remaining ends only decrease the count and can never raise the peak, so the sweep can halt here.

All starts consumed (si=3). Stop the sweep
after 4 events processed.

Timeline of busy-room count:
  t=0  : 1
  t=5  : 2   <- PEAK
  t=10 : 1
  t=15 : 2

answer = max = 2

We stop as soon as every start is placed; trailing ends can only lower the count. The peak concurrency was 2, so 2 meeting rooms suffice. Complexity: sorting dominates at O(n log n) time, O(n) space — the sweep itself is linear. The sort is what made a single left-to-right pass correct.