Coding is not the only thing required to be an excellent developer and contributor to your team and company. Sometimes you must gather requirements from users / customers. Sometimes you have to work with other teams or products to integrate them into your product.

There’s also the aspect of working with the rest of your team on whatever problems you are solving and not siloing yourself to just the problems you’re working on.

That and when you’re hit with new and interesting problems that have never been solved before, you cannot look those up in the leetcode manual and memorize them to solve. You have to actually create something on your own and apply whatever you’ve learned from programming in the past.

It’s like playing a survival video game with the detailed how-to always at your fingertips versus being in the wilderness having to survive on your own wits without a guide.

It does seem to be a thing with younger developers, who want to stay wfh and just work on jira tickets.

Any sensible developer learns early on that mostly the coding is the easy stuff - what Is the problem I am solving here?

I see this time and again from observation over 20 years. Also many great engineers don't have cs backgrounds and don't do well on whiteboard/leetcode

Not the person you're responding to, but my perspective is that there is often a false equivalency between academic understanding (solving hard/clever problems) and productive development (meeting deadlines, building/fixing projects). Many of the stereotypical developer interviews assume "good developers" who are good at one are good at the other. My anecdotal experience is that most are not, they excel in one or the other.

I don’t think they are exclusive, you can be a great engineer that knows all about the algorithms in CS books and keeps up on the latest research in parts of the academic field. They aren’t even different skill sets, just different places to find the knowledge. Game development and cryptography bear this out well. The top engineers are the ones that read all the papers and that can build solid systems based on them.

I don't think I framed it as exclusive, but that the intersection of both sets of skills is uncommon (I attest they are two different sets). Sure, you can aim to hire only people who excel in both, but the typical software interview certainly doesn't assess the latter.

some common engineering things that leetcode doesn't test for

    - using http apis and transforming the resulting data
    - using database queries and transforming the resulting data
    - navigating a large codebase
    - figuring out what tasks are important to accomplish
    - researching things you don't know
    - debugging a complex issue
    - evaluating tradeoffs
    - general engineering intuition

Doer/implementation vs abstract/big idea thinker.

thanks, can be useful tips for my future staff recruitment.

It's like memorizing the answers to an IQ test. A relative of mind knows all the answers, as he conducted the test on many occasions, but he doesn't have the max IQ.

Ye. Making up quick sort sort on the fly without ever seeing the solution would be really impressive, but reciting it from memory doesn't say much. If someone would implement "max sort" on a interview at-least you would know he didn't practice for the "IQ test".