It also doesn't resemble "real" work with regards to gathering requirements, clarifying ambiguity, weighing up trade-offs, making sure code is clear, etc. It tends to be a rote regurgitation exercise.
You can’t make blanket statements about software like that. Our field is way too varied.
For example, if you’re doing high frequency trading, then performance absolutely 100% matters. And knowing your data structures and algorithms backwards is part of that. On the other hand, if you’re building the website at a large company, the hard part of your job may be interfacing with the rest of the business. So networking and navigating corporate politics will be an incredibly important part of your job. And if you’re on a small team making a product for consumers, then your work will succeed or fail based on usability.
We could brainstorm dozens of other skills which might be important. Which of these skills matter the most depends entirely on the company and the role.
What they aren't good at is consumer-facing web services with graphical frontends, at least since Gmail or so. Even there, businesses seem to like the G Suite.
Chrome: hmm - was Chrome developed after Brin & Page left? I never realized this but OK you got me on that one if that indeed is the case.
Go: I liked it initially and I love the performance, but i don't necessarily love the language syntax and design.
The rest: mostly tools which make scaling Google's infrastructure easier. I don't count these as outstanding accomplishments but I suppose you may have had me here too (albeit the scope I was referring to mostly referred to regular ppl not infra teams but meh I suppose I'll give you this one as well).
if you dont do that in leetcode interview - you will not make it, or you will be graded as junior/entry level engineer.
No senior engineer will be passed without doing what you described during the leetcode interview
where there are much greater selective pressures in India and China to excel at this than there are in the US, raising this irrelevant bar to absurd territory if you value your time
Is there any evidence that candidates who do well on design interviews but fumble on leetcode would be any worse at the actual job?
people who cannot leetcode - a simple data structures & algorithms inteview - cannot understand runtime nuances of what they write.
This is how you end up with N+1 algorithms and exponential runtime.
For example look at all modern front-end in javascript - usually leetcode is more relaxed for front end, and you end up with ungodly gobbles of unnecessary loops inside loops wrapped in loops that traverse DOM for no good reason and freeze the browser.
it is the javascript people who import node libraries that contain 3 lines of code, instead of writing it properly
Primed recall can remain strong for many years, but leetcode often penalizes googling around to refresh your memory, even though that is what almost everyone should do before taking any further steps toward an implementation. Depending, it's often also the correct thing to do before choosing a library, the parameters to a function, code base organization, and lots of other details.
Of course, domain experts may be very strong in their specialty, but that's a special case with narrower scope.
I can hypothesize that testing for a "fast study" may have more predictive power. I have seen some interviews that are designed for this, leetcode adjacent but less antagonistic.
But anyway, I am spitballing, to be real with you.