If you're given a blank slate and asked to sort a list without using a library without any gotchas, complexity requirements, space requirements, expectations that the code is completely free of small bugs etc.; and you can't do that after some thinking even to a basic degree, then you're just not a good programmer.
As a programmer, your task is to find algorithms to solve problems. Sure, sorting numbers is a solved problem and in real life you should use a library. But you will not find a library for each problem you encounter, and sorting is a very simple problem to solve compared to anything you'll find in real life.
I agree, but how is applying pre-learned algorithms significantly better than using pre-build libraries? Both is about using an existing solution, instead of coming up with it on your own. The real approach would be to ask candidates to solve a problem that doesn't easily fit into any popular category, so that they have to come up with an original approach - but that is first hard to come up with, and 2nd it would require investing extra time on both sides, which usually neither candidates nor interviewer can afford.
Yes, that's a good point, and in our interviews we do try to take a slightly less well-known problem, at least one that doesn't have a dozen well-known named algorithms.
Still, even using a pre-learned algorithm demonstrates some level of confort with algorithms in general, and can be used as a stepping stone during the interview to shift the problem slightly to see how they adapt the algorithm.
For example, if a candidate is clearly taking their time and essentially working out the algorithm themselves, and succeeding, that demonstrates the skill and we can move to other problems. If the candidate just breezes through and finishes in 2 minutes, then we can change the problem ad-hoc to try to get them off the beaten track a bit (say, if they wrote quicksort, maybe ask about making it stable, or sorting even numbers differently from odd numbers, off the top of my head).
My point was that if testing for a skillset, using something that favors those who have toyed with a specific algorithm is the same as asking trivia questions.
Trivia does not provide evidence of skill, it demonstrates prior knowledge.
It would be better to introduce a unique situation that would place everyone at the same starting point.
If the expectation of the interviewer is to see if they know quicksort, then I fully agree with you. If the sorting problem is simply used as a (rather uninspired, granted) stepping stone to checking that the candidate has basic algorithm-finding skills, then I think it can serve this purpose (though less well-known but still relatively simple problems would be better). I gave an example in another thread as well, but in principle I would change the problem up a bit if the candidate is obviously producing a well-known algorithm; whereas, if the candidate is working out the solution themselves, I would be happy with that and move to other topics.
Even so, knowing very widely talked about programming trivia is still a signal for interest in the art. I'm not sure that sorting algorithms are a good example of what I'm thinking, but I always award extra mental points to candidates who seem knowledgeable about the field (e.g. they know the general consensus on manual memory management vs garbage collection). Still, I wouldn't consider these sorts of things dealbreakers by any stretch of the imagination.
As a programmer, your task is to find algorithms to solve problems. Sure, sorting numbers is a solved problem and in real life you should use a library. But you will not find a library for each problem you encounter, and sorting is a very simple problem to solve compared to anything you'll find in real life.