We’re generally talking about large complex distributed systems with tons of throughput.
As LC itself demonstrates, there typically are multiple ways to solve a problem. Most engineers will do the brute force approach and stop there because it does in fact solve the problem. And for most companies that will be enough.
The issue here is those types of solutions can be catastrophic for these larger tech companies… some algo that’s part of a tiny feature cab cause a massive performance regression.
When it comes to these algos, computer science dictates there is an optimal time and space complexity solution. There are also more clear and more obtuse ways to achieve what is technically an optimal solution from a performance perspective… often these can be found and discussed in the LC discussion sections. The more obtuse… ie trying to get to a minimal LOC, might be fun from a competitive programming perspective, but terrible for production code that needs to be maintained by coworkers.
So there is a craftsmanship aspect to it that goes above and beyond these algos, but ultimately there are optimal time and space complexity approaches that need to be adhered to.
Now no one is perfect. You’re not always going to come to an optimally performing solution. But if you’re good enough at this stuff, and your coworkers are good enough, it’s going to be rare that a PR enters the system that causes some notable bottleneck. And when it does, you should have the mental toolkit to quickly determine what happened.
Making a call to arms avoid this stuff as it stifles creativity is sorta like the folks who say learning music theory can harm someone’s ability to compose music. If you’re a pop songwriter, perhaps. But what if you need to compose a symphony? You’re just not going to luck into it with a basic understanding of music theory and advanced composition.
It’s just one kind of mental toolkit, and somewhat orthogonal to knowing the apis and design patterns of some framework you’re using to build a thins, the idioms of a language, etc.