I agree the process sucks and it's a hoop to jump through, but why take it out on the interviewer?
I've written integer programs, ray tracing simulation software for fields of heliostats, custom orchestration tools and deployment pipelines, etc. and not once has anything said or done during a whiteboard interview been relevant to any of it. The actual job is pretty much orthogonal to whatever the interviewer thinks they are figuring out during a whiteboard interview and as above the stuff I've worked on goes over the heads of 90% of the programmer population so 9/10 they can't and are not qualified to judge things properly but somehow they still think through the magic of the whiteboard they'll divine the candidate's true capabilities.
When working on hard problems I go to the library and don't stand in front of a whiteboard to see if I'm smart enough to reinvent some wheel. Chances are someone else has already figured it out and I just need to read some paper and then implement it. If they haven't figured it out then that means the problem is harder than I thought and will either need to rethink my approach entirely or spend my time on something else.
Unless of course the job is to stand in front of a whiteboard and wave furiously, in which case you should be using a whiteboard to interview.
I get that its a horrible thing for some to consider that there is creative freedom involved in work and not everything in life follows exact and well defined rules. Anything else, is just holding humanity back. I ve seen standards written by assembly programmers, still alive and walking the earth, torturing hundreds and undead for ever, because what is once set in motion.
Really good standards, standardize intentions. "Every Programm shall consists of layers and components. Every component shall be sperated by a interface."
A bad standard tells you how the interface has to look like- every time.
(Obviously, this goes both ways, shitty companies tend to have trouble getting good people to interview.)
Unfortunately, the whiteboard thing is not as standardized, so it's somewhat harder to teach to the test, but it is not impossible. People waste a lot of time I think when they can memorize a small number of basic algorithms and then learn to map the question given to one of those techniques.
But writing the code with a marker on a board definitely takes practice as well.
The available training materials are good, but they are not great. A focus on shortcuts would be nice. I remember my verbal SAT improving significantly just from the single tip to read the reading comprehension questions before reading the passage. I suspect there are similar tips that can improve your speed at figuring out the trick that solves these interview problems quickly.
So, I generally feel like it makes more sense to try to determine the actual aptitude when you have an opportunity, instead of trying to measure it by possible decades old proxy with huge and unknown variance. If you had good grade and/or spent some time studying for the interview, and really meet the hiring bar, you'll most likely do well in the interviews anyway. There's some noise in the process, and good qualified candidates are sometimes rejected, but from company's perspective, it's better to have some false negatives, than to give another metric that can be easily gamed, and get false positives. Google has enough qualified candidates applying for a job to make it not that big of a deal if you lose some due to the noise.
... then perhaps it's best to let them know and save everybody some time (including your own).