When n is small and constants/code-size dominate, which is common in embedded. Big-O describes large-n behavior, but firmware often sorts 8 readings or manages a 16-element queue. For such tiny inputs, an O(n²) insertion sort frequently beats an O(n log n) quicksort or mergesort on actual cycles, because it has a tiny constant factor, no recursion overhead, no extra memory, less code, and it's adaptive (nearly-sorted data approaches O(n)). Mergesort needs O(n) scratch space many MCUs can't spare, and quicksort has recursion and a bad O(n²) worst case. So you pick insertion sort for small or nearly-sorted data, and reserve the asymptotically-better sorts for genuinely large n. The principle: the crossover point matters, so benchmark at your actual input size rather than blindly trusting asymptotics.
Data Structures & Algorithms · Interview question
When would you choose an O(n²) algorithm over an O(n log n) one?
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
Time & Space Complexity
Big-O describes how cost grows with input size, and on an MCU you also care about the constants it hides, worst-case determinism (WCET), and the space-time tradeoff.