Written by Rahul · Frontend Engineer at Google · Updated 2025
If you've been coding for any amount of time, you've sorted data. But here's the thing — picking the wrong sorting algorithm in production can literally crash your service. I've seen it happen at Google when a naive O(n²) sort hit a list of 500K search suggestions. Let me walk you through what actually matters.
Why Should You Care About This?
In a frontend interview at Google, Amazon, or Meta — sorting complexity is the most asked topic. Not because they want you to memorize numbers, but because it shows you understand trade-offs. And in production? Choosing between QuickSort and MergeSort can mean the difference between a 200ms and a 3-second page load.
The Big Picture — All Sorting Algorithms at a Glance
| Algorithm | Best Case | Average Case | Worst Case | Space | Stable? |
|---|---|---|---|---|---|
| Bubble Sort | O(n) | O(n²) | O(n²) | O(1) | ✅ Yes |
| Selection Sort | O(n²) | O(n²) | O(n²) | O(1) | ❌ No |
| Insertion Sort | O(n) | O(n²) | O(n²) | O(1) | ✅ Yes |
| Merge Sort | O(n log n) | O(n log n) | O(n log n) | O(n) | ✅ Yes |
| Quick Sort | O(n log n) | O(n log n) | O(n²) | O(log n) | ❌ No |
| Heap Sort | O(n log n) | O(n log n) | O(n log n) | O(1) | ❌ No |
| Tim Sort | O(n) | O(n log n) | O(n log n) | O(n) | ✅ Yes |
| Radix Sort | O(nk) | O(nk) | O(nk) | O(n + k) | ✅ Yes |
The Ones That Actually Matter in Production
1. Tim Sort — What JavaScript Actually Uses
When you call Array.prototype.sort() in V8 (Chrome/Node.js), it uses Tim Sort. This is a hybrid of Merge Sort and Insertion Sort, designed for real-world data that's often partially sorted.
// This is Tim Sort under the hood
const users = [{name: "Zara"}, {name: "Alex"}, {name: "Mike"}];
users.sort((a, b) => a.name.localeCompare(b.name));Why Tim Sort? Real-world data is rarely random. Tim Sort exploits existing order in data (called "runs"), making it incredibly fast for nearly-sorted arrays — which is exactly what happens when you re-sort a table after one column change.
2. Quick Sort — The Production Workhorse
Despite its O(n²) worst case, Quick Sort is the fastest in practice for random data because of CPU cache locality. The key is pivot selection.
// Bad pivot selection - causes O(n²) on sorted arrays
function quickSortBad(arr) {
if (arr.length <= 1) return arr;
const pivot = arr[0]; // NEVER do this in production
// ...
}
// Good pivot selection - median of three
function quickSortGood(arr, lo, hi) {
const mid = Math.floor((lo + hi) / 2);
// Pick median of arr[lo], arr[mid], arr[hi]
// This prevents worst case on sorted/reverse-sorted data
}Real Production Issues I've Seen
Issue 1: The Autocomplete Disaster
A team at work used Bubble Sort for sorting autocomplete suggestions (they didn't know — it was hidden in a utility function). With 10 suggestions, fine. When the feature scaled to 500K suggestions for a power user, the UI froze for 8 seconds. Switching to the native .sort() (Tim Sort) fixed it instantly.
Issue 2: Unstable Sort Breaking UI
We had a table sorted by priority, then by date within each priority. An unstable sort (Quick Sort) was shuffling items with the same priority randomly on each re-render. Users reported "jumping rows." Fix: ensure stable sort or add a tiebreaker key.
// ❌ Unstable - equal items may swap order
items.sort((a, b) => a.priority - b.priority);
// ✅ Stable - add tiebreaker
items.sort((a, b) => {
if (a.priority !== b.priority) return a.priority - b.priority;
return a.createdAt - b.createdAt; // tiebreaker
});Best Practices
- Use the built-in
.sort()— it's Tim Sort in modern engines and is heavily optimized. Don't write your own unless you have a very specific reason. - Always provide a comparator —
[10, 2, 1].sort()gives[1, 10, 2]because it converts to strings. Always use.sort((a, b) => a - b). - Watch for mutation —
.sort()mutates the original array. Use[...arr].sort()orarr.toSorted()(ES2023) in React to avoid bugs. - For huge datasets, consider virtualization — don't sort 100K rows client-side. Use server-side sorting with SQL
ORDER BY.
Things to Avoid in Production
- ❌ Never implement Bubble Sort or Selection Sort for anything beyond educational purposes
- ❌ Don't sort inside render loops — memoize with
useMemo - ❌ Don't assume
.sort()is stable in all environments (it is in modern browsers, but not in older ones) - ❌ Never sort without a comparator function for numbers
When to Use What — A Decision Tree
- Small arrays (< 50 items): Doesn't matter. Use
.sort() - Nearly sorted data: Tim Sort (built-in) or Insertion Sort
- Need stability: Merge Sort or Tim Sort
- Memory constrained: Heap Sort (O(1) space)
- Sorting integers in a range: Counting Sort or Radix Sort — O(n)
- Huge datasets: Move sorting to the backend (SQL ORDER BY)
Interview Tip
When asked about sorting in interviews, don't just list complexities. Talk about trade-offs: stability, cache performance, adaptiveness to partially sorted data, and when you'd delegate to the database instead. That's what separates senior candidates.
Key takeaway: In 99% of frontend work, Array.prototype.sort() is your answer. Know why it works (Tim Sort), know when it breaks (no comparator, mutation), and know when to move sorting server-side.