Because at small n and on nearly-sorted data it's actually the best choice, and Big-O describes large-n behavior that often doesn't apply on an MCU. Insertion sort is in-place (O(1) extra memory, no scratch buffer that might not fit), stable, has a tiny code footprint, and a small constant factor, so for the tens-of-elements inputs common in firmware it beats quicksort and mergesort on real cycles despite the worse asymptotic class. It's also adaptive: on nearly-sorted data, like sensor readings that drift slowly, or a list that's already ordered except for a new arrival, its inner loop barely runs and it approaches O(n). That's why production sort libraries fall back to insertion sort for small subarrays. The asymptotic O(n²) only bites at large n, which embedded sorts rarely hit. So you pick it for small or nearly-sorted data where simplicity, no extra memory, stability, and the low constant win.
Data Structures & Algorithms · Interview question
Why might you choose insertion sort, an O(n²) algorithm, on an embedded system?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Sorting Basics
The O(n²) simple sorts vs the O(n log n) fast ones, and why on embedded the simple, in-place insertion sort often beats the asymptotically-better choice at small n.