Alright, so Mountain View is waking up now and you'll get comments from Googlers, so here is mine.
DISCLAIMERS:
1. I work for Google, but these opinions are mine.
2. Everyone at Google is expected to interview, but I no longer do, and have not for two or three years. I have a medical exemption because for anxiety. Trust me, I know just as much as any candidate how stressful it is to be in that room.
3. I interviewed candidates for software engineering jobs.
4. I was an intern 8 years ago and 7 years ago, then flipped to full time 6 years ago.
5. I _do not believe I would pass the interview process cold_. As an intern, I got to use feedback from my internships to count for half of the interviews I would normally need to take. This was clutch: I'm good as a software engineer but would tank most Google interviews. I studied hard and I took mock interviews with my team while I was an intern. I knew my way around the campus and the rooms weren't alien to me, so I felt more comfortable.
6. None of this is meant to be a defense or repudiation of the OP's experience, nor is it meant to be a defense of Google or Google's hiring process. It's just meant to offer my explanation of why things are they way they are (other people may have difference perceptions of course).
With all that out of the way...
I've never met anyone at Google who is under any illusion that the hiring process is where the company would want it to be if anyone in the process could wave a magic wand. Even 8 years ago this was true. From the outside looking in, the process is byzantine and the experience of the OP is not as uncommon as one would hope.
The only way to make sense of it in your mind is to pretend to be on the inside looking out. Think of the interviewing process as a result of a set of constraints:
* Constraint 1: Google skews very heavily for no false positives, thus increasing the number of false negatives.
* Constraint 2: Google wants to hire as many people as it can that meet the bar in order to grow the way it wants, and it gets an enormous number of applications each year. But "Google" the company still grounds out to actual people running the show, and juggling this enormous candidate load is unenviable at best.
* Constraint 3: Because of how many people are being interviewed and the high bar, each interviewer somehow need to judge a candidate's quality within just one hour. This leads interviewers to ask hard/really hard questions about things you likely won't ever code but candidates who did good in school (or were good at studying for the interview) would have a shot at. I would never do this as I don't think that's a good signal at all; I would always ask questions that were basically about standard coding. I'd even print out a sheet of code that worked but had a number of code health failures and would ask candidates to do a code review of it.
Google has two main goals:
1. Hire the right people.
2. Knowing that the false negative rate is so high, make sure the process is pleasant enough that candidates will come back again.
I think 1 is doing pretty well, 2 is not, and 2 is not because it's buckling under the constraints. I would always try to help on a micro-level by doing things like checking if the candidate needed water, food, bathroom, testing out the whiteboard pens and replacing the bad ones (if I was nervous and I found my pen wasn't working straight off, I'd be thrown for a total loop), giving them 5 minutes to recenter themselves quietly, whatever. But those micro-level interactions don't help the macro-level experience.
You can imagine many ways of interviewing that would be better if you didn't have those constraints. If I was CEO of a startup, candidates who passed basic screening would be given access to the code base and asked to work for a day or two on an open bug. That would give you signal on their coding ability, ability to see through the ambiguity in the bug, work through an alien code base etc. etc. It would be great. It isn't possible here because there's so many candidates to work through.
There have been multiple initiatives over the years to try and make the process better, each one small nudges rather than global overhauls to avoid rocking the boat too much. After all, the process does kind of work: I work with smart people who I like being around and have done across all the teams I've been on, so something is working in the results. I think interviewees can now use a laptop for writing code in a room, for example (don't quote me on it, I stopped interviewing before that).
So, that's that. I hope it helps in understanding things, at least.