Getting quicksort's boundary conditions right (avoiding off-by-one errors, infinite recursion, etc.) can be tricky.
Another popular algorithm that can be hard to get right is binary search.
Ikea instructions are like an Easy to Medium level test in reverse engineering skills, with occasional EXPERT TIER SUPREME level skills needed because of subtleties.
but if you don't understand it at all... I have bad news for you
Then again, maybe that’s not important to the author - it is a pretty funny illustration to those in the know.
This is how I understand it after reading these instructiöns, without looking up any further explanation:
1. Choose a random element as the 'center' point of the sort
2. That element defines the maximum 'height' (value)
3. Anything that is larger than that value, is moved to the right side of the 'center'
4. Anything that is smaller than that value, is moved to the left side of the center. After this, the array is partially sorted.
5. The sorting process is repeated on both 'sides' independently, picking a new random center element and so on
What isn't clear, is how often the process needs to be repeated, or when the algorithm 'knows' that the sorting has been finished - surely it can't be just three iterations?
By now I've already looked up how the algorithm actually works, but the above is what I got out of the illustration :)
> surely it can't be just three iterations?
To save others a search: you stop when the remaining sub-arrays are sorted by definition (ie. [] or [x]/size of 0 or 1).
They'll have a highly optimised small sort and use that whenever sorting very small things. So e.g. IPN Sort the Rust stdlib unstable sort will do this for 16 items, even though for a big slice it'd quick sort them by default, once it's down to say 10 items they're going to the specialised small sort.
Any serious "fast" sort in 2025 will be a hybrid, using several of these classic sorting algortihms, plus other insights to produce the overall best solution to their problem on modern hardware.