No, it doesn't. I understand the need to sort out good developers from bad developers, but when this exam-style interview scourge finally dies out, it won't be soon enough.
All you're doing is optimizing for developers who can create sorting algorithms. If you're a company that specializes in developing new, groundbreaking sorting algorithms, that might make sense. But if you're a company that specializes in, say, B2B software, it doesn't make any sense at all. If one of your developers needs to sort something, they'll just use whatever's available in the libraries or frameworks or languages your company uses.
It might be good to see if they understand the differences between n^2 and an n log n algorithms, only because you want to see if they understand the basic concepts of performance in algorithms versus performance in code.
Why not ask applicants to submit examples of projects they've done or code they've written, pick a few that look interesting to you, find portions of the code or projects that look especially interesting, and ask the candidates about it? You'll get to see what kind of work they do in general, and asking them about their code should weed out the few cheeky bastards that submitted something they didn't actually write.
