> 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.

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.

You didn't understand my point. It is that leetcode does not help at all (for 99% of jobs) because you are not faced with these problems.. you can of course claim that the juniors which excel in leetcode questions will be good at these other things I mentioned but I don't think there is much proof for that.

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 can do those leetcode bits. They just take time and energy. They can be fun in their own way, but I grew bored of them quickly. But all of the things you listed and leetcode have one glaring difference, collaboration. leetcode is a very solitary experience. You are basically picking at a puzzle by yourself and 'grind it out'. Yet all the other things you listed involve making everyone around you understand those bits. That is almost an entirely different skillset. Hell yesterday I sat back and just listened in a meeting to 3 different people state the issues they were having. I was able to help each one. Because 'been there done that', and another skill I picked up over the years listening to what everyone is saying. Not one bit of that was leetcode. But organizational and the same errors many devs stub their toes on. "oh go talk to so and so about that", "which error are you seeing in the log? oh that means blah blah blah, go talk to so and so and have them fix the wizzy wuttsy". Most issues in most organizations is either money, time, or knowing who to talk to. Big O, hash tables, CS style issues, are how you build the thing to sell. But day to day the business is run by people, time and money.

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.

This line of reasoning makes no sense at all.

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.

I'd be pretty damned suspicious of someone claiming to be a maths professor who couldn't tell me what seven eights are.