We want people to know all computer science (etc.) topics, not the exact four-hours-worth we happen to ask in an arbitrary interview. The idea is to randomly sample your knowledge, not to have you study and recite the answers to a few questions.
It's an imperfect process, yes, but I'm not sure how this is one-size-fits-all. Giving you the questions beforehand would be a one-size-fits-all interview; we would see how well you study for tests. By asking practical questions that apply your knowledge of programming, we can see how you'll actually do your work. And, interviewers are not robots; if it's clear you don't know something about obscure category X, we'll move the discussion in the direction of something that you know about. I know nothing about document classification, but I know a lot about "code health". So my interviewers asked refactoring questions instead of document classification questions.
It's a pretty flexible process, and most of the people I've talked to about it seem to like it. It seems scary at first because you don't do many graph traversals in your day-to-day work. But once you get up to the whiteboard and start thinking, you realize, "wait, I do know this stuff". And that's what the interviews are designed to do: skip the easy stuff that we know you know and see how you answer questions that are just out of reach.
(I learned a lot from my Google interviews, and was actually slightly surprised that I had been hired. At the interview, I had a lot of new questions to think about, and I learned a lot in the form of hints from the interviewers. All in all, a great experience. Better once I knew I'd been hired, though :)