What is sorting, and why does it matter?

Sorting means putting items in order by some key — numbers from smallest to largest, names alphabetically, orders by date. It's the most used algorithm in programming, and in interviews it's one of the most useful tricks: once data is sorted, a hard question often becomes an easy scan.

Sorting the numbers 5, 2, 9, 1, 7 gives 1, 2, 5, 7, 9. Below, a stable sort of four records by grade: Ann B, Bob A, Cy B, Dee A becomes Bob A, Dee A, Ann B, Cy B. Records with the same grade keep their original order: Bob still comes before Dee and Ann before Cy.

Why sorting matters

Sorted data has structure that unsorted data doesn't, and many algorithms depend on it:

Searching — binary search finds a value among a million sorted values in about 20 steps instead of a million.
Duplicates and groups — equal values end up next to each other, so one pass finds duplicates or counts groups.
Two pointers — pairs with a target sum, closest pairs and merging all rely on order to know which pointer to move.
Intervals and schedules — sorting meetings by start time lines up overlaps so one scan can merge or count them.
Everyday software — database ORDER BY, leaderboards, file listings and search results are all sorts.

Words you'll see

Comparison sort — decides the order only by comparing two items at a time (a < b). Bubble, selection, insertion, merge, quick and heap sort all work this way.
Non-comparison sort — uses the values themselves as positions, like counting how many of each number there are. Counting, radix and bucket sort.
In-place — needs only O(1) extra memory besides the array itself.
Stable — items with equal keys keep their original order. This matters when you sort by one key after another (by name, then by grade).
Adaptive — runs faster when the input is already nearly sorted.

The speed limit: O(n log n)

No comparison sort can beat O(n log n) comparisons in the worst case. There are n! possible orders of n items, and each comparison has two outcomes, so at best it rules out half of the orders still possible. Telling all n! apart needs at least log₂(n!) comparisons — about n log₂ n. Merge sort and heap sort reach that limit; the simple sorts take O(n²). Only non-comparison sorts go faster, and they need extra facts about the values (small integers, a fixed number of digits).

Sorting in your language

You'll rarely write a sort from scratch at work — every language has a fast, well-tested one. Know how to call it, and how to pass your own comparator: a function that returns a negative number when a should come first, a positive one when b should, and 0 when they're equal.

1function sortNumbers(nums) {2  return [...nums].sort((a, b) => a - b);   // without (a, b) => a - b, JS compares as text: [10, 9, 1] -> [1, 10, 9]3}

JavaScript3 lines

Sorting by a key looks the same in every language — tell the sort what to compare:

JavaScript  people.sort((a, b) => a.age - b.age)
Python      people.sort(key=lambda p: p.age)
Java        people.sort(Comparator.comparingInt(p -> p.age))
C++         sort(people.begin(), people.end(), [](auto& a, auto& b) { return a.age < b.age; })

The rest of this introduction opens up the classic algorithms one at a time — each drawn, simulated and timed — so you know what these built-ins do and when to write your own.

Key takeaways

Sorting arranges items by a key; once sorted, duplicates sit together and binary search and two pointers work.
Comparison sorts can't beat O(n log n); counting and radix sort can, by using the values themselves.
Stable keeps equal keys in their original order; in-place uses O(1) extra memory.
In JavaScript, always give sort a comparator for numbers — the default compares them as text.

Was this helpful?