Google is infamous for jerking people around in the interview process. I had a very similar experience, as did several people I know.
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
> 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"
Apparently they missed this classic HN discussion:
> I could not spot a scenario in the first 5-7 min of interview.
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.
When people say "grind leetcode" they don't mean it as a tool to get better at these kinds of problem solving. What they basically mean is that if you "grind leetcode" you have a better chance of being asked a question in these interviews that you have solved before and simply write down the solution during the interview.
If they're IQ tests, then why does doing a whole bunch of leetcode questions make me better at it? Isn't IQ supposed to be relatively stable throughout one's lifetime?
I've done hundreds and I have gotten better, but only to a point. At some level it's not pattern recognition anymore, just inspiration. And I'm not smart enough for that.
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.
Do thousands then and get back to me. It's all patterns, this "inspiration", is just patterns, your just not seeing it yet.
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.
I dedicated a lot of my spare time to it in college (and after) too. What did I get for it? I make just $200k a year at the least impressive FAANG and literally everyone considers me to be a mental defective.
> The feedback I got was "candidate does not know idiomatic use of modules & classes"
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).
It's quite a common pattern these days: I often see candidates who choose a language because they think it's better suited for interviews, not because they know it well (we leave the choice of programming language to the candidate).
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.
The root comment is saying the interviewee knows the language well enough to consider one solution better than another solution.
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.)
I really well versed with Python, Golang & Rust. I will not choose Rust for interviews. For me, Python is much more productive in an interview setting.
I didn't mean to imply that this applied to your case. Just a general observation (rather frustrating for someone like me, who wants candidates to do well but not that infrequently sees them being let down by their own choices).
Yeah... reminds me of a past coworker. He spent weeks writing weird comments in code, then writing weird code to read comments. From the actual source files. Then when deployments didn't work, he said they worked on his machine the deployment must be broke.
To solve the hiring problem that seems rampant in the industry, I propose for all resumes that get past the auto-filter, we just implement a lottery system. Maybe it'll be even more effective than the current method!
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.