Why Some Ways of Sorting Are Much Faster

The plain-language idea

Picture sorting a hand of playing cards. You pick up cards one at a time and slide each one into the right spot among the cards you're already holding. It works. It's intuitive. It's how most people sort in real life without ever thinking about it as an algorithm.

Now picture a much bigger pile — a thousand cards on a table, face down. Sorting them one at a time, sliding each into place, would take a very long time. A faster approach: split the pile in half, sort each half separately, then merge the two sorted halves back together. Each half gets split again, and again, until you're comparing tiny piles, then merging your way back up to one big sorted pile.

Both approaches end in a sorted result. The difference is what happens as the pile grows. Sorting one card at a time gets slower roughly in proportion to the number of cards squared — double the cards, and it's roughly four times the work. The split-in-half approach barely slows down by comparison — double the cards, and it does only a bit more than double the work.

Why does this matter to you? Because "sort this" shows up constantly, and knowing that some sorting approaches scale far better than others — even before you memorize any specific one by name — is most of the practical insight an interviewer is actually checking for.

See it in a real thing: sorting a hand of numbers, one at a time

// Insertion sort: like sorting cards in your hand, one at a time.
function insertionSort(numbers) {
  for (let i = 1; i < numbers.length; i++) {
    const current = numbers[i]; // the "next card" we picked up
    let j = i - 1;

    // slide bigger cards one spot to the right to make room
    while (j >= 0 && numbers[j] > current) {
      numbers[j + 1] = numbers[j];
      j--;
    }
    numbers[j + 1] = current; // drop the card into its correct spot
  }
  return numbers;
}

console.log(insertionSort([5, 2, 4, 1, 3])); // [1, 2, 3, 4, 5]
// Fine for a small hand of cards. For a table of a thousand,
// the "split the pile in half" approach does far less total work.

What people usually miss

Watch out

• "Slow" doesn't mean "wrong." Insertion sort gives a correct answer every time. For a small hand of cards, it's honestly the practical choice — the speed difference only starts to matter once the pile gets big.
• You don't need to memorize a fast sort's code to talk about it well. Knowing the split-and-merge idea, and why it scales better, covers most of what actually gets asked.
• JavaScript's built-in .sort() already uses a fast approach. You rarely need to write a sort by hand in real code — this lesson is about recognizing the trade-off, not replacing the built-in.

The genealogy: sorting the array you already know

This connects back to the arrays you already know from the JavaScript track — sorting is reordering one, nothing more exotic than that. It also sets up why binary search, a later idea, needs a sorted list to work its trick at all.