almost all of Google loses money and makes products that get cancelled. so if you want to lose money and make products that nobody uses or gets cancelled, then i guess leetcode is a good idea.
That’s not a development fail. They need better product people maybe? Also, google has money to spend so the bar for a launch may have been much lower in the past.
thats my point. what if leetcode tests filter out everyone who is good at making useful products or services, in favor of people who can memorize how to solve puzzles.
The people who make those decisions aren't doing leetcode tests. Do you think that Thomas Kurian passed a leetcode test? Of course he didn't, the people who make business decisions are in another pipeline that is just a normal management interview.
When did they start doing leetCode style interviews? LeetCode looks to have been founded in 2015; of course, though, that doesn’t mean Google couldn’t have had a similar in-house format that predates that founding…
But it is hard to say how much leetCode style interviews helped. Post-2015 Google already had quite a bit of momentum.
My understanding is that LC style interviews largely replaced "brain teaser", "how would you move mount fuji?" type questions so at least you're testing CS concepts and basic coding ability.
Cracking the Coding Interview came out in 2008 and had a short section talking about the Google interview process, which I believe was system design + a coding problem that would probably be close to a modern LC question.
I am cusrious what you mean by "LeetCode-style". My understanding is "present a problem, only take the resulting code, judge that".
I did a fair number of coding interviews (for SRE positions) at Google (I don't actually know how many in total, but 25-30 is probably a safe guess) and, yes, it started with a small problem that should be solvable in well under half the interview time. I only used problems that passed my "is this fair to the candidate" screening (look at problem, try to write a working solution, if that takes more than 7 minutes, the problem is not fair).
The value in the interview comes from (a) listening to the candidate narrating their thought process during the coding, (ii) discussing the solution with the candidate, sometimes in terms of complexity, sometimes in terms of correctness, depending on what is on the board, (3) refining the code written (add more functionality, change functionality).
For a language I knew, I tended to overlook small syntactic mistakes (a whiteboard does not have any syntax highlighting) and if there was any questions about library functions, I would give an answer (and note down what I said, so that would be the standard used when judging) and the bulk of the score came from the discussion about the code, not the code itself.
If that matches what you mean by "LeetCode-style interview", that's certainly been in place since at least 2011. If it does not, things may have changed, but at least the aim wit ha coding interview back when I was still at Google was less "get some code judge, on the code" and more "get some code, judge the discussion about the code". It is also entirely possible that interviewing for SWE positions was different frmo hiring for SRE positions.
They always used to be famous for dumb questions that made you think like how many golfballs can you fit in a school bus, why are manhole covers round etc.
