Interval Scheduling — O(n²) Blowup Led to 30s Timeouts
Naive O(n²) interval comparison caused 30-second timeouts on imported Outlook calendars.
20+ years shipping performance-critical code where algorithms decide the bill. Drawn from code that ran under real load.
- Interval scheduling finds max non-overlapping meetings using earliest finish time greedy
- Minimum meeting rooms: sort starts, track active end times with a min-heap
- Merge intervals: sort starts, merge consecutive overlaps in a single pass
- All three run O(n log n): the sort dominates
- Production trap: assuming sorting by start time works for max intervals — it does not
You have a list of meetings, each with a start and end time. Two problems: (1) What is the maximum number of non-overlapping meetings you can attend? (2) What is the minimum number of rooms needed to host all meetings simultaneously? Both have elegant greedy solutions.
Interval scheduling appears in every operating system (process time slots), every calendar application (meeting conflict detection), and virtually every resource allocation problem. The three variants — maximise non-overlapping intervals, minimise rooms needed, merge overlapping intervals — are among the most frequently asked algorithmic interview problems at top companies.
All three have elegant O(n log n) greedy solutions, but the correctness argument for each is different. Maximum non-overlapping uses earliest deadline first with an exchange argument. Minimum rooms uses a priority queue sweep. Merge intervals is just careful iteration. Knowing all three and why each works — not just what to code — is what distinguishes thorough preparation.
Why Interval Scheduling Is a Greedy Trap
Interval scheduling is the problem of selecting the maximum number of non-overlapping intervals from a set, each defined by a start and end time. The core mechanic: given intervals (s_i, f_i), choose the largest subset where no two intervals overlap. The canonical greedy solution sorts by finish time and picks the earliest-finishing compatible interval — O(n log n) and optimal.
What matters in practice: the greedy algorithm works only when intervals are unweighted. Weighted interval scheduling requires dynamic programming — O(n²) naive, O(n log n) with binary search. The key property is compatibility: two intervals i and j overlap if s_i < f_j and s_j < f_i. The DP recurrence builds on the last compatible interval before each job, which is where the O(n²) blowup hides if you don't precompute.
Use interval scheduling whenever you need to maximize throughput under exclusive resource access — CPU scheduling, meeting room allocation, bandwidth reservation. It matters because the naive DP is deceptively expensive: 10,000 intervals can produce 100 million compatibility checks, turning a 10ms problem into a 30-second timeout in production.
Problem 1 — Maximum Non-Overlapping Intervals
Greedy insight: always pick the interval that finishes earliest. This leaves maximum room for future intervals.
Problem 2 — Minimum Meeting Rooms
Use a min-heap tracking end times of active meetings. For each meeting start, if the earliest-ending active meeting has ended, reuse its room.
Problem 3 — Merge Overlapping Intervals
Sort by start time, merge consecutive overlapping intervals.
Why Earliest Finish Time is Optimal
Claim: picking the interval with the earliest finish time is always in some optimal solution. Proof: suppose optimal starts with interval A instead of E (earliest finish). Replace A with E — since E finishes earlier, this can only improve future compatibility. By induction, greedy is optimal.
When Greedy Fails — Weighted Interval Scheduling
The earliest finish time greedy does NOT work when intervals have weights (values). A short, high-value interval might be later than a long, low-value one. For weighted interval scheduling you need dynamic programming: 1. Sort by end time 2. Use DP[i] = max(weight[i] + DP[p(i)], DP[i-1]) where p(i) is the last interval non-overlapping with i. This is O(n log n) with binary search for p(i).
Common Techniques — Because Sorting Isn't a Personality
Interval problems look cute until you're three hours into a bug where your merge logic misses an edge case. The truth is there are maybe four patterns that cover 90% of what you'll see. Memorize them, don't worship them.
Sorting is the obvious one. You sort by start time when you need to chain intervals forward — merging, room counting, overlap detection. You sort by end time when you want to maximize count (earliest finish wins). If you don't know which axis to sort on, you haven't understood the problem's constraint.
Sweep line is the nuclear option. You flatten every interval into start/end events, then walk the timeline tallying active intervals. It's overkill for simple merge, but it's the only sane way to find peak overlap or handle point queries.
Prefix sums and segment trees? Those are for when your intervals aren't cheap O(n log n) sorted scans. If you're reaching for a segment tree in an interview, you better be solving range queries over mutable intervals, not a glorified calendar merge. Don't confuse sophistication with necessity.
Identifying Problems Involving Interval Manipulation — Read the Tell
Most interval problems announce themselves with specific language. If you hear "meetings," "appointments," "schedules," or "time slots," you're in interval territory. But the real giveaway is the operation: merge, count, find free time, or calculate duration of overlap.
There's a subtler pattern too. Any problem that gives you pairs of numbers and asks for something about "non-overlapping" or "maximum set" is almost certainly an interval scheduling variant. The moment you see a conflict detection between two ranges, stop pretending it's a geometry problem and sort the damn intervals.
What trips up juniors is disguised intervals. A problem might hand you server start times and durations — you need to compute end times yourself. Or it gives you string timestamps and wants the busiest hour. That's still intervals, just wrapped in parsing. Don't fall for the dressing. Strip it down to [start, end) and apply your tools.
If you find yourself writing three nested loops to compare every interval pair with every other — stop. You missed the pattern. Go back to the problem statement. Look for the operation keyword. Then sort, greedy, or sweep line. That's your playbook.
Naive Interval Scheduling Caused 30-Second Timeouts
- Always profile with production-like data volumes before assuming algorithm choice is irrelevant.
- Interval scheduling problems often feel small — but calendars grow fast.
- When you see an O(n^2) algorithm in an interview solution, that's a red flag.
Key takeaways
Common mistakes to avoid
4 patternsSorting by start time for max non-overlapping intervals
Using '<' instead of '<=' when checking overlap for meeting rooms
Merging intervals without clarifying overlap definition
Applying greedy to weighted interval scheduling
Practice These on LeetCode
Interview Questions on This Topic
Why does sorting by end time give the optimal solution for interval scheduling?
Frequently Asked Questions
20+ years shipping performance-critical code where algorithms decide the bill. Drawn from code that ran under real load.
That's Greedy & Backtracking. Mark it forged?
4 min read · try the examples if you haven't