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:
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.