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.
This is curious to me, and it's not just in your comment that I've seen this.
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.
> 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.
How much time have they spent using the standard frameworks that most companies use everyday? Could they even model a standard relational schema? Do they know anything about automated testing?
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.
Most developers are doing CRUD apps or at most apps where the complexity is in the business rules and process.