They do it because they know they can get away with it, but I do wonder if they have a backup plan if the lustre of working for Google ever fades, because it's an open secret that their interview process is a fucking nightmare for no reason.
Absolutely! To add, the amount of nit-picking that happens is staggering. I was downgraded from strong-hire to lean-hire because:
1. I did not use classes in Python. That problem could easily be solved using simple functions. The feedback I got was "candidate does not know idiomatic use of modules & classes"
2. I did not use one of python's standard lib functions and instead I coded it myself (I could not remember it at that instant)
3. I could not spot a scenario in the first 5-7 min of interview. I eventually spotted it and coded it well within the time limit.
Somehow I felt that I am supposed to feel grateful for lean-hire
Apparently they missed this classic HN discussion:
Many googlers probably haven't read this blog-post from some time ago [1]: "Python Is Not Java". I mentioned that at my first interview for a Python programmer job ~15 years ago, i got hired (truth be told the interview was for a small-ish startup, not for a behemoth like Google).
Sometimes this works well, sometimes it really backfires on them. Coding is one of key rubrics on which we assess software engineering candidates, and if the only signal I have is that they don't know know their chosen language very well, it's hard to justify scoring that rubric highly.
And this was misinterpreted by the interviewer as not knowing the language.
An effective interviewer would have asked "Why are you doing it this way?" instead of assuming - wrongly - it was all the candidate knew.
This actually matters. Before you even get to coding skill you want people who can parse reality accurately, and not make incorrect assumptions about what's happening in front of them - either out of narcissism and arrogance, or because of poor communication skills, or because they're following a set process which is bureaucratic and inflexible and operates with a poor signal to noise ratio. (Among other possible reasons.)
But I get what you are saying though.
This is endemic and part of a much wider malignancy in the tech interviews. Cram two medium-to-high difficulty questions in the span of 45 minutes and require the candidates to solve them both on the spot. In other words, you have at most 20 minutes to work out a complete solution to any given problem.
In practice that means that you need to come up with the correct base solution in the first 2-3 minutes, because there is no time to actually work through the problem.
I call these types of interviews Epiphany Lottery.
Or which ones are young and single with no responsibilities outside of work. Which is likely a feature, not a bug.
Not only correct solution but also generate alternatives to showcase what other things you know to get strong-hire.
Example:
This problem was asked in Google: https://leetcode.com/problems/cat-and-mouse/
It is actually based on a paper [1]. Plus it seems it is expected that one needs to know about 'alpha-beta' pruning algos for such problems.
If you solve this using dfs ... its basically gtfo
[1] https://www.semanticscholar.org/paper/Undirected-Cat-and-Mou...
This one, for instance is expected to be completed in 30 minutes. I spent 2 hours on it yesterday and failed most test cases. I'm a failure.
Its true on some degree, that you need some intelligence, but I have a few close friends who are FAANG, they are definitely not the best developers I've ever worked with, only difference is they really really cared about getting into FAANG. Getting into FAANG was basically their life ambitions, so they dedicated literally all there spare time to it.
Darn the wheel of the world! Why must it continually turn over?
He was hired by FAANG less than a month later.