What it is
Many problems that look combinatorial become simple once you sort the input, because sorting turns "any two elements might interact" into "only neighbors or a moving pair of pointers can interact." Interval problems become mergeable once sorted by start; multi-value target-sum problems reduce from O(n^k) brute force to O(n^(k-1)) once one value is fixed and two pointers close in from the ends of a sorted remainder; array-merging problems become a single linear pass once both sides are ordered. The sort itself is rarely the point — it's the setup that makes a cheap pass afterward correct.
When it applies
- You're working with intervals and need to detect overlaps, merge them, or count how many are active at once — sort by start (or by start and end together) first.
- You need pairs or triples of values hitting or approaching a target sum — sort, fix the outer value(s), then two-pointer the rest.
- You're merging two already-sorted sequences, or need to place one sorted sequence into another with unused capacity, in a single linear pass.
- Needing to preserve the original order of elements in the output means sorting destroys the information you need — look for an index-preserving approach instead (or sort a list of
(value, index)pairs, not just values).
Tells in the problem
- Intervals given "in no particular order" or "not necessarily sorted," with a request to merge, detect conflicts, or count overlaps.
- "Return every triple/pair summing to..." or "closest to a target," especially when the output must avoid duplicate combinations.
- Two arrays or lists each already sorted, needing to become one sorted result.
- "In non-decreasing order" already given as an input property you're expected to exploit, not re-derive.
- Cars, intervals, or events described by a start value and a rate/end, where the question is really about which ones catch up to or overlap with which others.
The classic mistake
Sorting by the wrong key, or only one of two keys that matter — sorting intervals by end instead of start silently breaks a merge (you lose the ability to just compare each interval to the last one kept), and sorting only by start when two intervals can share a start value but need a secondary tie-break produces an order that looks sorted but isn't stable for the problem's purposes. The other common failure in sum-finding problems is not skipping over duplicate values after fixing an anchor, which produces the same triple multiple times — the fix is to advance past repeated values explicitly, both for the fixed anchor and for the two pointers once a match is found, not to rely on a set to paper over the duplication after the fact.
Questions to start with
- Meeting Rooms — the simplest sort-first check: order by start, then compare each interval only to the previous one.
- Merge Intervals — the same sort, extended to actually combine overlapping runs instead of just detecting them.
- Merge Sorted Array — no sorting call needed at all, since both inputs are already ordered; the pattern here is exploiting that order with a linear merge instead of concatenate-and-sort.
- 3Sum — the classic fix-one-value-then-two-pointer reduction, with explicit duplicate skipping.
- 3Sum Closest — the same reduction, but tracking a running best distance instead of collecting exact matches.
- Car Fleet — sorting by starting position (from the front) turns a physical catch-up simulation into a single stack-based pass.