I agree with all of those things. A real engineer has soft skills and the ability to look beyond the immediate problem to see what is at the heart of the issue. They can see the effects of a solution and see the problems that might arise from it. They see connections.

Leetcoders just find the most efficient solution for the problem at hand. They don't see connections to other problems, whether current or potential. They're a scalpel when you really need a massage.

I've seen leetcoders throw away less-efficient, safer solutions just to implement something more efficient and clever. And when things fail, they're nowhere to be found. Too busy with whatever current Story they're on.

You don't want to be a real engineer in business though. Real engineers do all of the hard work and thinking while getting paid less than management.

I've done management. It's mind-numbing and soul-sucking. I'll take the pay cut to have the stimulation and challenge of being an engineer.

One has time and patience to practice for leet code interviews, while the other is too busy for it.

All of that non-technical stuff wont help you when the bridge you signed off on collapses because you had no idea what the blueprint was actually saying.

I think a bunch of this "engineers don't actually need to know stuff" comes from a generation that never had to deal with things that might kill people if it fails.

A lone idiot can certainly foul things up, but look at how catastrophes usually unfold.

The right information is usually somewhere in the organization, but it isn’t shared or acted upon appropriately. The Challenger report is pretty clear that it was “an accident rooted in history”. They had a decade of data about O-ring performance in the cold, but it was ignored/overruled in the decision to launch. It certainly wasn’t the case that The New Guy just grabbed some rubber from the wrong shelf and blew up a space shuttle. The Mars Climate Orbiter was lost because of a metric vs imperial mixup, but it wasn’t one dev who capriciously decided to work in inches; there were whole teams that weren’t synced up.

Engineers certainly need to know something, but I’d bet the farm that a team of B+ engineers with good coordination can run circles around “rockstars” that won’t work together.

In fact, I'd go so far as to say that if a lone idiot can wreak havoc, it's usually a coordination problem further up.

To me a real engineer is good at engineering, what you described sounds like a good HR manager.

I don't think HR is usually on that level.

For example, suppose your team generates and shares some kind of data. You want to change the wire format. You could just go ahead and do it, letting the chips fall where they may, but I think that's bad engineering/engineering management.

It'd be better to coordinate with the folks consuming the data. Can you make their migration easier? While you're making a breaking change, are there others that would make sense to roll in? Are there times when it'd be better/worse to roll out the new version? Being proactive about this sort of stuff seems like good engineering to me.

All of those things are people management, and I agree people management is an important skill to have if you want to work in a big company in particular it isn't related to engineering. A guy who is completely non-verbal but makes a solar panel that is 5% more efficient is a great engineer, perhaps not liked by those around him but still a great engineer.

Terry Davis was a great engineer and he had the worst commutation skills you could imagine.

HR does not do that. They don't prioritize nor coordinate - unless you count getting people to company dinner as coordination. They do communicate, but rarely about product or how things are done or should be done.

And I don't mean that as criticism, I mean ythat as "it is not their job"

Same. The biggest point that I didn’t see in comments so far is that Leet Code exercices are really fast to evaluate and it accelerates the pipeline for filtering and hiring. Even a recruiter can “evaluate” them. Just looking at the code more or less and if the automatic tests pass. Which is not the case for exercises for engineers. If you want a real engineering problem it would be mostly about architecture which are long and hard to evaluate. Or about how to break down a rotten program and apply SOLID and other like that to redesign it. Same thing long and hard to evaluate.

Are those properties exclusive? Someone has to write std::sort

The problem is not LC. The problem is companies not tailoring the interview to the position.

I don't know about that, the best engineers I have met were introverts. (They preferred reading to "communicating.")

I mean, I'm an introvert and I prefer working with code, not people, but I've found my own productivity has skyrocketed now that I'm making an effort to reach out more and raise questions about bigger issues than just the immediate technical issue I'm facing.

I've worked with many people much smarter than me. And I've watched smart, very technical engineers silo themselves off. And then I've watch smart technical engineers that make an effort to communicate and lead initiatives to improve the codebase, make arguments to management for tackling tech debt, and speak up during technical grooming to propose better solutions. And while the siloed off introvert might be able to write better code faster, the engineer that is looking at the whole picture makes an entire team move faster.