[dmurray]

One way to look at it is that your ability to contribute is one part familiarity with the stack, the problem domain, and the company's development process: one part "generic ability/competence".

You're going to learn the first part on the job. It's rare - especially in Google's hiring - that you want to hire someone for their deep familiarity with the tech stack or problem domain. So you select for the second part.

But your test for the second part still involves specialising in some process. Take home tests or pair programming exercises aren't "culture-blind" any more than whiteboard tests. So a large important part of the industry standardised on a "development process" of writing code on a whiteboard, a "business domain" of advanced-undergrad-level data structures, and a "tech stack" of "pick any language you want, or a reasonably rigorous pseudocode". If everyone learns that to the same degree, the remaining differences between the candidates are mostly in part 2.

There are some downsides that get trotted out on HN every time: you may reject someone who's really good but didn't take the time to focus on undergrad data structures, you may reject someone who is particularly bad at whiteboard stuff (typically due to nerves), your process is easier to train for recent CS grads from good universities. But every system has downsides. This one is reasonable for Google and not-terrible for you, but you may be able to do much better by focusing on one of the sets of people Google's process underrates.