What killed me was speed.
I didn't think the questions were particularly difficult. Certainly they were (mostly) all solvable in about 20 minutes and the code shouldn't take more than one whiteboard-height. Use this knowledge to your advantage: you're not going to get a super complicated algorithm that will take lines and lines of code. The problems were also pretty interesting, they weren't textbook crap like "Go through a binary tree in some order". Lots of the questions are online, and you may as well practice using what people have leaked. At least two problems came up in my interview that I'd seen before (one was even mentioned in a Google talk about interviewing technique).
Being concise and correct matters, maybe this was easier because I coded in Python and there's less boilerplate.
My feedback was that they had no problem with my problem solving skills or communication, but that I was simply too slow converting ideas to code. The best interviews were the ones where I finished early and we went on to chat about other problems in a more casual manner.
Similarly test the crap out of your solutions.
1) Make sure you understand what you're being asked to do. Whiteboard a test example without any code at all.
2) Discuss your approach and mention any big O problems (e.g. "I could brute force this by searching all the pairs, but that would be O(N^2)"). Settle on a solution that your interviewer approves of, then start coding.
3) Test your code again with known input/outputs. You should be comfortable using your brain as a REPL.
Otherwise have fun - enjoy the office tour, the free food and drink and the problems. They're all friendly, smart people.
Would I work there? I don't know. If you're good, you can soar in Google. If you're not pro-active, you can rot in a boring department forever. What concerned me is that they couldn't guarantee what job I'd be doing when I started, even though I'd explicitly applied for a niche computer vision role that I was well suited for (PhD level).