LeetCode has no correlation with great software development. Great development is more about paying attention to the end users, having an eye for usability and design and great communication & the ability to execute. The current LeetCode churning explains why Google hasn't produced anything worth using since Brin & Page checked out and why so much of software today is absolute garbage - but it is what it is I suppose. I suppose its better to screen for IQ and desparation than you know...people who love developing great software. Let them keep doing what they're doing while treating their own people like disposable garbage during hard times (like Google & Meta just did) and we'll see what they'll churn out over the next decade or so (I'm not expecting anything from either of these companies).

> LeetCode has no correlation with great software development. Great development is more about paying attention to the end users

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.

I don't disagree with you and I agree with your take on understanding data structures and algorithms ... it is important, but making 80 to 90 percent of your recruitment process based on this and on playing games with quizzes and LeetCode is idiotic. There are lots of other factors that play a vitally important role in creating great software and most big companies do NOTHING to pay attention to these factors albeit I fully admit to this being hard to test for. That's why I offer every company I'm recruited into to do a paid (or free albeit open source) work sample test if they want to do so. Most don't take me up on this offer and I think its idiotic but it is what it is.

This isn't really fair. All of Android, the Go programming language, TensorFlow, MapReduce, Big Table, Kubernetes, V8, Chrome are all very good engineering, software that stands the test of time and is likely to remain in use for decades. It's not garbage. They're great at libraries, plumbing, infrastructure layer tooling that enables Internet scale.

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.

Google acquired the early android team and they were vital in making it succesful: https://www.androidauthority.com/google-android-acquisition-...

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).

A lot of places will also do a desgin interview to cover this aspect of the job.

Which raises the question of why do the other kind of interview at all. I mean the leetcode nonsense whose end state is often a theatrical performance: “I’m pretending to invent this clever algorithm on the fly although I’ve practiced it for weeks”.

Is there any evidence that candidates who do well on design interviews but fumble on leetcode would be any worse at the actual job?

Leetcode is simply testing whether you studied Computer Science, took Data Structures & Algorithms course, and read the CLR book on algos and practices it. Nothing else. This is really freshman level cs work. very simple.

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

Maybe. My experience is that a lot of the unprimed recall gets weak very quickly without practice. There's irony in testing for skills that a fresh graduate may do better at than someone with substantially more experience.

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.

You don't need to be good at leetcode to make a performant and well written frontend. You don't even need to know data structures, algorithms, or Big O notation.

what do you mean by N+1 algorithms?

IME it's a test in which it is easy to grade many people in a way that it is really unlikely that two people end up with the same grade. That is what leetcode achieves and that is really the majority of the reason it is used. So it is just very convenient for hiring. In India, we have companies coming to hire students from colleges, and as the first filter, they give you three leetcode questions, and average the number of test cases you passed in each of them and rank you based on that. I spoke to one of the companies, they said that they had _very_ few people that had the same score, and it was easy to choose within those small sets by reading their resume/whatever.

> It tends to be a rote regurgitation exercise.

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

> gathering requirements, clarifying ambiguity, weighing up trade-offs, making sure code is clear

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