What it is
Interval problems give you a collection of ranges — meetings, busy blocks, coverage windows — and ask you a question that depends on how they overlap: how many merge into one, how many rooms or resources you need at once, which ones to keep or discard. The technique that unlocks nearly all of them is the same: sort by an endpoint (usually start, sometimes end), then make a single sweep, carrying forward just enough state (a running merged interval, a count of active ranges, a heap of end times) to answer the question without re-comparing every pair.
When it applies
- The input is a set of ranges and the question is about their overlap, union, count of overlaps, or minimal-removal/coverage.
- A greedy choice made in sorted order (extend the current merged range, or evict the interval that frees up soonest) can be shown to never lose the optimal answer.
- You have many point queries against many ranges ("which interval covers this point, and how small is it") — here the sweep is replaced by sorting endpoints and binary-searching per query.
- If the ranges must be scheduled with more state than "how many are active right now" (e.g. weighted selection where value, not just count, matters), you're closer to a dynamic-programming interval problem than a straightforward sweep.
Tells in the problem
- Intervals given as
[start, end]pairs, explicitly said to be unsorted or "in no particular order" — sorting is the first move, not an afterthought. - "Minimum number of rooms/resources" needed to accommodate everything without conflict.
- "Merge" or "combine" language, plus a rule about whether touching endpoints count as overlapping (a detail every interval question states explicitly and that changes the comparison operator you use).
- "Minimum number to remove" so the rest don't overlap — a greedy keep-the-one-that-ends-soonest problem in disguise.
- Many queries, each asking which of many ranges contains a point, especially with size or "smallest" as the tiebreak.
The classic mistake
The mistake interviewers report most is skipping or mishandling the sort, or getting the overlap comparison backwards for the interval's endpoint convention (closed [a,b] vs. half-open [a,b)), so intervals that should merge don't, or ones that shouldn't get merged do. It happens because the sweep logic itself is short and easy to write correctly once the input is sorted the right way — so the actual bug hides in the one-line comparison (< vs <=) that decides "do these touch or overlap," which differs from problem to problem based on the stated convention. Before coding, write out on paper what happens at a shared endpoint for this specific problem, and pick your comparison operator to match it exactly.
Questions to start with
- Merge Intervals — the base case: sort by start, then sweep and extend or start a new merged interval.
- Meeting Rooms — a yes/no version that only needs to check each interval against its immediate predecessor once sorted.
- Insert Interval — reuses the merge logic but exploits the fact that the list is already sorted, so no full re-sort is needed.
- Meeting Rooms II — extends the sweep to count concurrently active intervals rather than just detect any overlap.
- Non-overlapping Intervals — the greedy angle: proving that keeping the interval that ends earliest is always at least as good as any alternative.