When I interviewed at Google in 2006, one of the interviewers asked me to write code for solving a particular problem. I replied along the lines of "ok I need to think about this, it's not obvious how to solve it" and started thinking. Time ticked away. Five minutes. Ten minutes. Fifteen minutes. The interviewer started reminding me that he needed me to write some code and if there wasn't anything for him to copy dow…
The goal is not to see how many algorithms you know. Algorithms are easy to learn on the job.
The goal is to see how you think in a social setting. How you approach a vague, imperfectly stated problem. Do you ask questions to gather more requirements? State assumptions? Then, based on that, how you try to break it down into smaller pieces. Are there different ways to model the problem or lenses you can apply? Can you think of this as a graph? A tree? A database? Can you incorporate ideas from the interviewer on the fly?
The software engineering job is about taking vague problems and turning them into working code with a help of a team, and the interview process is trying emulate that as best as possible under the weird limitations of an interview.
You can pass an interview without getting any of the "answers" "right" and you can fail them even while blasting out perfect algorithms on the whiteboard.