3 ms·
> the only way you can write merge sort is if you memorize it Nah. You only have to remember the central idea (if you have two sorted "runs", you can merge the
by dirkt 4y ago
> the only way you can write merge sort is if you memorize it
Nah. You only have to remember the central idea (if you have two sorted "runs", you can merge them into a single sorted run). You draw a quick diagram to explain the idea, you go ahead and write code that does it.
Then you apply recursion, and write down the overall algorithm (subdivide into runs until you can use some other method to sort it, then merge recursively).
Bonus points if you can explain the circumstances when this is useful (when you want to sort data that is a lot larger than your main memory, but you can write it on disk or tape). Which is kind of obsolete today, unless you are again dealing with BIG data (everything old is new again...)
- ramraj07 4y agoThat’s a great question. Thanks for continuing to ask these so I can avoid those orgs. When I do come to having to decide on a sorting algorithm, I can refer to the code and algos and then decide. All I need to be able to do is understand the algorithm when I see it not memorize the differences between quick and merge sort. I’m actively working with multiple Olap and regular db solutions and my teams responsible for keeping 100 billion row tables in the most queryable format and it’s never been possible for me to make such a choice, only on whether I use spark or redshift or snowflake. So what exactly would you achieve by asking this question? The irony is I was rejected by 5 companies for not being technical, accepted by 1 where I’ve been thriving for years now at one of the most technical roles in the org.