I guess you need to talk to Norvig or whoever designed their data-driven process and the definition of good hire they wanted to achieve. It used to be that when you joined Google you had no clue what your project will be before your first day, so I guess they wanted to maximize success rate on blind assignments to teams/ideas. For that certain abstract skills are more important than your past accomplishments you might not be able to reproduce in different environment with different rules. It's their money after all, they are desirable, they can select for whatever they wish.

So, to be clear, you thought good reasons for an unrealistic testing process were:

* Argument from authority (because Norvig)

* "We might want to put a front ender in a back end job and vice versa so we need an interview process that accounts for that"

* Tests of "abstract skills" - as in, skills you won't actually use - are more important than tests of non-abstract skills which you will.

* "It's their money"

Nope.

> * Argument from authority (because Norvig)

No. I suggested you might want to ask Norvig why did they decide so

> front ender in a back end job

I think it's a bit different. It's like you are creating completely new stuff like Big Data 15 years ago where frontend/backend separation didn't exist yet. Likely the same holds for various machine learning roles right now. So those categories we will be using in the future have to be invented first, and for that you need slightly different approach