May be I am a little overconfident, but I always go into an interview and treat it as a formality to getting the job. By the time I'm in front of the whiteboard, I've already spoken to the recruiter and know what they are looking for, seen the job req to know what technologies they care about, and I've had a phone screen. Why wouldn't I be confident?
Another interviewer told me at the end of the interview to submit an application and they can get an offer emailed to me by the end of the day. We did a collaborative white board design session and spent a lot of time just talking.
Either all of the job offers I've gotten have been mostly just discussions or I talk tech so much I can't tell the difference between an interview and a typical day at the office.
I think that the perception that it's just a hazing process comes from a failure to look at it from the company's perspective. Most people know that they're good programmers (whether it's true or not...), and so they're like "This is bullshit...why do I need to prove my worth at the whiteboard when I know that I'm a good programmer." But the cost of a bad hire is really, really high (both for the company and for the employee), and the applicant pool is skewed through adverse selection, and a company knows nothing about you when you come in to the interview. Many people with stellar resumes can't actually code; some that can code don't actually want to work with you and would be bad cultural fits; and some outright lie on their resume. They're trying to figure out, in a 50-minute hour, whether you'll be productive on the particular problems that that employer faces.
Especially in the context of Google's public commitment to increase diversity among their engineers, it strikes me that revamping their interviewing process to eschew whiteboarding ought to at least be considered - it would be amazing PR for Google if they swallowed their pride and innovated in this area. And it would have a real effect outside Google, since so many companies' interview processes mimic Google's.
I see comments on HN time to the effect of "Why do I need to know how to traverse a tree or sort a trillion 32-bit integers? Why should I care about big-O notation? When will I ever use those skills on the job, when I could just Google for a standard library function?" I used those skills all the time when I worked at Google. When your data set is measure in petabytes, you can't just reach for a stdlib function, you have to actually know how the algorithm works, in depth, so you can implement it across thousands of machines. And any algorithm slower than O(N log N) is not going to work. Even in frontend work, I used tree traversals all the time because JQuery's byte cost was too high to use on Google services.
They have been taking other steps to increase diversity, though, like redacting names & genders on resumes, ensuring that every female candidate has at least one female interviewer, and trying to source candidates from non-traditional (i.e. non-Ivy-league, non-brand-name-tech-company) places.
Has Google innovated much in the interviews themselves in the last, say, 10 years? My perception is No. I get the impression that Google's old-fashioned process is a point of pride that they hang on to because it works (at least, the business is succeeding) and they are afraid of change. But it's a missed opportunity for a technical leader to advance the status quo in our industry.
For example, onsite, Google interviewers will still ask you to write code or pseudocode on the whiteboard. That's something they could re-examine (perhaps by giving an option of whiteboard or computer, and ensuring a level playing field between the options). They could get some good publicity from re-examining this, I think.
I interviewed on-site successfully at Google Seattle about a year ago, and I was given the option between writing code on a whiteboard or in a text editor on a Chromebook, being projected onto the screen in the room, so the interviewers could easily follow without awkwardly looking over my shoulder.
Of course, I picked the text editor. I can't imagine wanting to write code on a whiteboard. However, I did use the whiteboard voluntarily as a thinking and planning aid.
Unfortunately, I also heard that the text editor option was only available at certain offices at that point. I really hope coding in a text editor becomes a universally available option because it's just so much more natural. It essentially put my mind at ease and helped me think more clearly.
On a more general note, my strategy, which seemed to work well for me, was to treat the whole situation like a pair programming task. Even though the interviewer won't directly tell you what to do, they will often comment on things if you question yourself out loud enough.
Actually, speaking of looking at it from the companies perspective, in 2010 google and several other big name silicon valley companies were successfully sued because they all agreed with each other not to cold call each others employees to try to recruit them. They actively worked to try to make it harder to switch jobs from one company to another.
Right after that, they started doing whiteboard interviews, which serve the same purpose of making it painful to switch companies, but without the risk of being sued.