[bitL]

Getting to Google is more difficult than getting to Harvard. They built their process that way risking rejecting great candidates in order to minimize false positives, bad hires, according to their definition of bad hire. So the Homebrew author could have expected it, it happens all the time. I object to using the same criteria throughout the industry on most jobs these days though, instead of only on top-end ones. I have nothing against top companies having top interviews, they are usually fun if you are good.

[crdoconnor]

Explain to me the justification behind using an interview process that deliberately placed no emphasis on realism.

This guy wouldn't be using binary trees at Google. He hasn't used them before. They are of minimal relevance in his area of expertise.

[bitL]

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.

[crdoconnor]

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"

[bitL]

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