Here's my take on it: the interview is testing your ability to "show" that you absorbed the content and process of your 4th year data-structures and algorithms classes. The whiteboard process is all about showing them that you can regurgitate what those courses taught you, likely in the manner that the prof taught you. You're essentially playing "professor" for them in front of a "class", for a short period of time. Not showing them that you can write code. The code you write on the whiteboard will look nothing like anything you'll ever write at Google.

I think one way to do well in that interview, is to pretend you're the professor and they're a student, and you're working through course material.

In the end, it's just showing them that you passed the socio-cultural hurdles they think are necessary, even if they no longer explicitly check GPAs and which school you came from at interview time.

Why?

Google is more often than not the first job these employees have after school, and many stay there almost forever after. A large percentage are masters or PhDs.

Google is founded by two Stanford grads, both children of academics, who never worked in the industry outside of Google.

Academia is hence the reference point against which Google measures things.

Google is structured in many ways just like a university. Publish or perish (Design docs, PRDs). Thesis committees (perf "calibration" committee, interview committees, etc) and review (intense code review). Even down to the physical "campus" structure. On site cafeterias, even housing/dorms (GSuites, etc)

It's something that was very foreign to me having worked in the industry for a decade before, without a degree.

In addition to what others have said, that's an accessibility concern. There are many people who have a physical inability to handwrite.

https://en.wikipedia.org/wiki/Dysgraphia

In some ways I'm grateful for Covid's impact on the job market because I now have many alternatives to physically drawing on a whiteboard. I can use TikZ as fast as my professors can draw, and I can put that on a monitor in a conference room. I've even used it on exams before.

I would probably struggle for reasons unrelated to my actual competence as a programmer if I was forced to use a physical whiteboard during an interview. Your comment made me appreciate that I'm graduating into a different world than 4 years ago.

When I interviewed at Google I was making iOS apps using Objective-C at my current job, so I decided to stick with that for the whiteboard so I wouldn't blank out on some syntax at an inopportune time.

Big mistake. The method names get so long I was kept running out of space on the whiteboard and it took forever to write it.

I don't remember exactly what I wrote anymore (it was over a decade ago), but this site[1] has some examples of really long property and method names in Cocoa (its framework), like:

splitViewControllerPreferredInterfaceOrientationForPresentation

or

initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel:

Anyway, for that and other reasons I didn't get the job (I apparently didn't prepare quite the right things, despite preparing for a few hours every night for the two weeks prior, which is how long the recruiter gave me before flying me to Mountain View, so my performance for at least two of the six interviews I had that day were a bit weak).

[1]: https://github.com/Quotation/LongestCocoa

I've never had any company let me write pseudocode. I once tried to write "vec" instead of "std::vector" and the interview told me to write valid code on the whiteboard. (And I did explain that I was to avoid writing "std::vector" repeatedly).

I'm sorry, I don't see how that relates to what I was asking. To be clear, I agree, I just don't understand why you chose to write this in reply to what I wrote.