Most developers are doing CRUD apps or at most apps where the complexity is in the business rules and process.
Absolutely. Unless you're working on a greenfield project or refactoring code for extreme performance, understanding the operational side of the business will get you more points towards the mythical 10x programmer status than algorithms.
I can't count the times I've seen scope creep and deadline slippage because the developer didn't really understand the need & use case and built something other than what was required.
But why is there this assumption that if someone studies Leetcode and algorithms then it means that they can't do anything else? Why is there this all or nothing mentality?
If someone studies Leetcode and algorithms, wouldn't one assume they know other things as well in the software engineering realm? I have plenty of friends in the Bay Area who are thriving at FAANG who studied algorithms and Leetcode intensely.
And I've seen developers come from doing Node green field APIs at Netflix to waist deep in a 15 year old Java application with Spring MVC and some underlying Struts yet to be removed and don't understand why debugger stopped going any deeper and they lost where they start 10 classes ago from shared modules.
Then they don't understand how refactoring a core message for alerting customer across the sight has tight coupling, wanted to something fancy and broke the key business features, try to argue it's better but a business unit just list functionality of it's product. Instead of researching, and coming up a plan with a team to refactor using TTD and Strangle Vine method from the legacy tightly coupled code, to a separate module with better testing and following SOLID principles.
Welcome to multiple Fortune 500 companies.
If they were told a web page was slow would they know enough architecturally to know how to find the bottleneck and no the solution for solving it? No the answer is not based on finding the o(n) complexity of reversing a binary tree.
Of course not, the main purpose of the leetcode is to ace the interview.
Doesn't mean they do not know any of those questions you mentioned above.
I, for example, did all you mentioned above and also practicing leetcode.
So, trust me when I say I don't object in the slightest to being asked to study and learn things. LeetCode-style problems look like one form of recreation to me.
And yet, I still think this comment is shortsighted because:
* I'd guess a lot of what's on LeetCode isn't exactly untrodden territory for any developer that got their start before 1995.
* Distinguishing oneself can work in the individual case, but it generalizes poorly. Imagine employers and would-be job-seekers alike internalize LeetCode knowledge as a standard distinguishing mark. Like college degrees, distinguishing points often over time become standard expectations. The likely outcome is that about as many devs in their 20s & 30s can brandish the same "distinction" that devs 40+ can and the incentives to prefer youth perform about the same.
Individual efforts to improve ones lot are a good place to start, but they rarely solve systemic problems.