If I was asked to do some comp-geom problem involving convex hull algorithms or intersecting lines, I would be boned. I haven't touched any of that kind of thing years. Even something simple like a quicksort or Dijkstra's algorithm would be a challenge for me to code off the top of my head. I shouldn't have to study for a job interview, I should be interviewed on things that I do on a daily basis.
The thing with a lot of these algorithms is that they seem so obvious and simple when you know the answer, but they still took a very clever person to discover them in the first place.
A good interview question should be a question where the algorithm to implement is trivial (e.g. binary search), but the application is novel.
A good algorithm question I was asked a while ago was to reverse a string in place ("hello world => "dlrow olleh"). Then after completing this task, I was asked to reverse each word, but keep the words in order ("hello world" => "olleh dlrow").
Neither of them is a difficult algorithm. There's no specialist knowledge required to implement them, but there is a degree of logic and problem solving required.
The problem itself wasn't meant to be hard (although apparently a lot of candidates completely failed at it). It was a vehicle for me to discuss how I went about solving problems. It also ended up being a good discussion about why unit testing makes life a lot easier. My code itself was incorrect at a couple of points due to off-by-one errors, but the interviewer wasn't worried at all, because he was aware that it was a whiteboard, and these kinds of errors would be picked up in a real coding environment with testing very quickly.