The crucial thing here is recognizing that the algorithm needs to take shortcuts to avoid having to compare each element to every other element (which would result in a O(N^2) algorithm) but only to some of the other elements and to do it again when sorting those elements. This is the reason why "divide work in piles and handle each of those piles by dividing it in piles and handle each of those piles etc" ends up with O(N log N) complexity.
The hard part is picking those elements, and to handle working with those elements. Picking is hard because you must choose well to get the subpiles equally sized. Managing is hard because you cannot spend too much time moving things around if you want a fast algorithm.
For instance, QuickSort works by choosing an element (traditionally called "pivot") and divide the work in two piles. One having elements smaller than the pivot, and the other having larger. Then quicksort each pile, and merge the two sorted piles back. If the pivot is the smallest element each time, you end up with an empty sub-pile and a big subpile with all the elements but the pivot. This will result in a worst case of O(N^2). If you choose well, you get half-sized sub-piles and a running time of O(N log N).
So a typical way to choose the pivot is to look at three randomly chosen values from the pile and choose the one in the middle. This at least avoids the empty sub-pile.