When I was young I also was pretty good at these interviews and loved doing coding contests and such for fun. However when I joined a big company I learned what really is hard about software "engineering".
It's dealing with legacy code, finding and fixing bugs in highly distributed systems, understanding tickets from customers, managing integration of different components, balancing tests to be enough but not to be too much.
In general the hard tasks are very rarely one specific well determined problem such as finding a node in a tree in the most performant way.
Right, if you can't do any of those and can only do leetcode you will get hired as a junior. Do you think that juniors need those things? No, of course not, they need to learn that on the job. So juniors gets leetcode. Now, since all juniors can do leetcode, why shouldn't we require seniors to also know it? Otherwise we would hire seniors who are worse than the seniors we grow ourselves. You can say that seems like an arbitrary requirement, but it makes sense, and there is no lack of senior engineers wanting to get hired at FAANG. And getting X years of experience isn't an accomplishment, even the dumbest software engineer will get there after X years.
Of course you will gain experience anyways over time. But all your leetcode skills will fade into meaningless very fast when you see what the actual problems are.
I have been meaning to go back and grind some of those problems out again. Just to refresh my memory on them. But notice I have to 'refresh my memory'? These problems usually do not come up. You are usually clicking some if conditions together and a few for loops. Nothing fancy. The interesting bits are figuring out someone elses framework using docs written in an afterthought and what 3 other methods do I need to call to fill out param 4 of this method just so I can get this thing to do what I want.
Imagine a math professor would be required to be as fast in answering questions regarding times tables as a child in third class. I bet you wouldn't be able to hire almost any math professors any more because almost all of them would lack this skill!
Nobody would be of course so stupid to judge a math professor by asking them questions about the times table.
Well, but one, and only one, industry is bonkers enough to do exactly this.
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.
Then the software industry isn't for you.
I'm definitely not saying it doesn't require dedication and brainpower and (in the right places) formal methods. But the overall creative process, and most especially the end product (and the aesthetics) of what we produce are about as far from a musical symphony ... as anything you could think of.
There's a good Steve Jobs quote about this, which I couldn't easily find, but which completely nails this distinction. Something along the lines of: "No - we're not here to build something that that people will look at in a museum hundreds of years for now. Very little of what we do will last for more than 10 years or so. It's about meeting people's needs in the here and now."
(Or to that that effect; I am horribly mangling the original).
It's a very different thing to bust out a bunch of features for a consumer product w/ relatively minor concerns relating to load/perf and something that operates at bleeding edge scale and complexity.
This is a funny take on it as pop music is 99.9% just some basic music theory put in the shaker and than pressing the random shuffle button. The rest is mostly just dull and boring work.
That's the reason why after people once figured out how to actually do it are able to produce constantly hits for decades thereafter.
No it's not. No more than writing a successful novel is a matter pressing the random shuffle button on all the distribution of plotlines and clichés you've seen before.
Sometimes the best answer is the one that maintains an API that was introduced in a beta that one customer is using. Sometimes the best answer involves breaking a 15 year old API that the entire country's electrical grid requires. But in both cases we're always looking for a single answer, a One Ring to Rule them All. The end-point or approach-point trade off considerations are IMHO, the real issue.
And thereby distract us from the very central fact you have articulated.
The problem is that this almost inevitably leads to a decline of the company.
I'd say it's more like a "Yes and no." But it's definitely not a binary. Your "No" characterization is partially valid. But only partially.
And what's a great what to introduce mistakes and fuck up an existing product or team? By being overly confident about one's binary "No" answers.
No.
Once a company grows to a sufficient size the goal stops being delivering products and starts being not ^&*£ing up the product that generates a lot of money. The aim is to hire people who won't get things wrong, either by making errors or by introducing new unproven ideas.