The best coders I've ever worked with rarely memorized the nuance little algorithms that they want you to regurgitate during these interviews. The ones that I know that are capable of this are terrible coworkers because they lack other necessary skills to function in an organization or team environment. This is anecdotal but sort of sticks with me.
The interview processes used by these software giants weeds out the kinds of people that have made the biggest differences in the companies I've worked for/with. From my experience they weigh their judgement much more heavily on the actual implementation of code instead of the understanding of code, decisions and overall design.
Knowing how to code a mergesort is not as important to understanding the wider uses of mergesort and when an altered algorithm would suit the problem best or when it would struggle to provide you the right performance at all.
Maybe these companies want code monkeys that can put down exactly as the design is given to them and the process works grand for them, but from an outsider looking in it seems like they miss out on a lot of great talent due to the rigorous screening process.
"Knowing how to code a mergesort" is specifically not what they're looking for, in my experience. The idea is to come up with a problem that requires an interesting algorithm that very few people will know, and see how the candidate reasons their way to an answer.
Many people implement it wrong. The best programmers know how to check their work, and will be asked during the interview to check.
Who doesn't know that (x + y) / 2 can overflow?
But the people who you really want to filter out have no idea or intuition that a problem can be solved by slicing it into two. That's the key idea behind binary search (and indeed, much of computer science).
I've never understood these vague hand-wavey claims about it being more important to know when and how to use X or a modified version of X than to be able to implement X (here X is mergesort, but could just as easily be some bit twiddling or a TCP connection or just about anything). How can someone simultaneously claim that they understand an algorithm well enough to know when best to apply it (and when to modify it!) and also admit that they can't actually implement it.
If you can't muddle through a basic implementation of mergesort 45 minutes, I can't believe that you are actually in a position to know when mergesort is a good or bad option, and certainly not that you are capable of writing a custom version for some domain-specific needs.
If someone wants to claim that it's simply not necessary to know mergesort, that's a reasonable stance (though I disagree). But to claim to truly understand it without being able to implement it seems like a bit of a fib.
The interview processes used by these software giants weeds out the kinds of people that have made the biggest differences in the companies I've worked for/with. From my experience they weigh their judgement much more heavily on the actual implementation of code instead of the understanding of code, decisions and overall design.
Knowing how to code a mergesort is not as important to understanding the wider uses of mergesort and when an altered algorithm would suit the problem best or when it would struggle to provide you the right performance at all.
Maybe these companies want code monkeys that can put down exactly as the design is given to them and the process works grand for them, but from an outsider looking in it seems like they miss out on a lot of great talent due to the rigorous screening process.