So, it's worth mentioning that there are two types of algorithm questions.
You seem to be complaining about the "show me merge sort" style, where the interviewer picks a commonly-taught well-known algorithm. I have, in practice, seen this style exactly once (maybe I'm missing a broader trend, though) and it thus comes off as a strawman.
The other type involves solving problems that most interviewees, by shear numbers, can't possibly have seen before. Here, you're testing for on-the-spot thinking, not memorization. This is what I actually see when I interview.
Because in practice, how many people need to implement merge sort? 99% of them should call `List.sort` and be done. But the algorithm for traversing this strange dual-tree structure or whatever probably isn't in the standard library, and I do need someone who can do that.
And why do you think this is the best way to test for on-the-spot-thinking? I know I personally need a bit of time to soak in an algorithmic question to arrive at a viable conclusion. I might have some theories or hypotheses at first, but in the context of a 45 minute interview, it's simply testing nothing other than whether or not I've been exposed to this particular problem before. I happen to be great at thinking on the spot when I need to improvise through a problem or debug a problem, but that would fail your metric because you asked the wrong question.
I know this may come as a great surprise to you, but not all questions of a person's abilities can be answered by whether or not they can write a joint scheduling implementation in the amount of time it takes to get through a short lunch.
I just wrote this comment on another thread here, I think it is relevant:
I will freely admit my algo knowledge isn't where it needs to be. But I know an algorithm's need where I see one, and consistently. The problems always contain a very specific problem space:
1) sorting
2) Large tables of information
3) categorizing
In nearly every case, the appropriate, well researched, proofed, Ph.D approved answer is a quick google away. If you're asking algorithm questions in your interviews, all you're looking for is someone's ability to conjure from memory an appropriate approach. Congratulations, you hired a flash card.
You know who I want to hire? Someone who shows creativity and drive through their experience (usually surfaces as having their hands in a lot of disciplines both CS and non), and someone who learns quickly. If they can implement an algorithm (not needing to conjure it on the spot), that's all I need. By the way, no self respecting algo researcher/analyst sits down for 45 minutes to come to a correct and efficient solution to an algorithm problem.
Enjoy your grad students. I'll take a maker any day.