> replaced them with real engineers

nice gatekeeping. Shame on them for working to get a job they want.

After seeing all the unreliable and buggy software, i think more gatekeeping in IT would probably be beneficial.

You wouldn't let someone do surgery on you that hasn't been to medical school.

Systemic problems being blamed on individuals is not going to help. Of course society is a shared responsibility model essentially but it means even a highly skilled and otherwise technically competent and qualified engineer in an inadequately structured system can regularly produce garbage work. Having to hire nothing but the best to achieve decent or viable output IMO moreso implies that the processes or systems are lacking than whether people are even capable of output of the desired feature set.

As an adult its your responsibility to produce sensible quality despite social factors. You can not expect society to hold your hand.

I disagree.

Culture is important at companies. Without it quality engineering can’t/won’t happen. People will rise to the bar set by their leadership unfortunately.

Example: The engineering of the Boeing 737 Max

Source: - https://www.netflix.com/title/81272421

Page 4, Part 1.1 from https://www.vdi.de/fileadmin/pages/mein_vdi/redakteure/publi... :

> Ingenieurinnen und Ingenieure sind alleine oder – bei arbeitsteiliger Zusammenarbeit – mitverantwortlich für die Folgen ihrer beruflichen Arbeit sowie für die sorgfältige Wahrnehmung ihrer spezifischen Pflichten, die ihnen aufgrund ihrer Kompetenz und ihres Sachverstandes zukommen

Translated with Google translate:

> Engineers are solely or – in the case of collaborative work – jointly responsible for the Consequences of their professional work as well as for the physical performance of their specific duties, which are due to them due to their competence and their expertise

Carrying this responsibility is a (indirekt) requirement for being legally able to call yourself engineer here.

Edit: a Netflix movie is a form of entertainment and not a valid source.

I understand this but there’s a huge gulf of nuance between expecting hand holding and keeping your head down while bad management expects great work output and results despite problems of their individual failures either.

It's more about professionalism and stricter standards of engineering and less about being "good despite bad context".

You can hire the best artisans for your pot making company and make some of the best pots. However, sooner or later you will encounter problems like disparate outcomes of quality (due to different people having different standards of style, crafting and discipline), unpredictability and reliability.

An engineer role is to standardize processes and turn things like quality into a predictable outcome. It's not just about being good and not being bad.

Unless the allegedly consolidated decided role of “software engineer level 123” is just a fiction recruiters believe in.

What you are describing doesn’t match my lived experience in this industry

IMHO IT should be less geeky an "leet" and more professional.

The quality of a product shouldn't rest solely on having faith that you hired good programmers by chance.

The rigor of an intro level algorithms course at a serious school far exceeds what is expected in a FAANG Leetcode interview.

Sure, that's true. I haven't taken one in over 25 years. I don't remember enough of the fine details off the top of my head to solve these well. But I can count on one hand the number of times it's held me back in real life.

Instead in my day to day I'm able to recognize when a problem needs something beyond the braindead solution and a sense of roughly where the solution lies, and am able to then go do a bit of research on the topic.

Solving leetcode hard style problems in ~45 mins off the top of one's head is just not a problem many developers face in their jobs. I agree that these tests demonstrate some information, but the ability for that person to be a good developer is not among that signal.

I generally agree, but in the case of algorithms courses you generally know what you're expected to know for tests, and for course work you have ample access to course materials.

Getting a random question from an infinite pool and completing it with fewer resources under a short time crunch is a different game.

The low-level/assembly course I took had tests that felt like puzzles, and those tests were a ton of fun to take. Can't say I've had the same feeling for leetcode puzzles.

What if my surgeon went to med school and was top of class, but had an attending who insisted on using the wrong tools? Or there was another surgeon on the team who created the "architecture" for a brain surgery, but for some reason in order to get to the brain they went through the chest. There can be many reasons for unreliable and buggy software that are completely unrelated to the developer.

An actually relevant test metric might help.

You are just apologizing for fraternity hazing

Good engineers learned their craft long before any school got ahold of them. The really good ones skipped the handholding.

Good engineers are professional engineers. A good engineer does a good job on what's expected on them.

A good engineer does not have to be a leet hacker, in the same way a good architect does not have to be a geeky concrete fanboy.

This is where you get attitudes like: "If you haven't been programming since you were six, you're rubbish and we don't want you."

I will take a programmer from age 6 over a dozen alleged “software engineers” performing “best practices” theater.

The former can deliver good software with less bugs, the latter might be able to, but are more likely to bikeshed endlessly, while being hamstrung by “best” practices that turn out to be inapplicable in a given domain, or even damaging.

Do wake me up when software engineering becomes a standardized practice that isn’t a mere cargo cult.

I swear, if I read one more comment about doctors and surgery and licensing I’m going to have to diverge on a rant exposing the multiple flaws in popular SE best practices.

Is it gatekeeping? They hire so many junior devs, do you not think it’d be possible to strip the team down by hiring far more capable engineers? Would Google crumble if they only hired senior devs like Netflix? I’m convinced they hire so many purely because they have the money and managers want bigger teams to go up the managerial track.

It stops their competitors from hiring them and it means they won't start new adtech companies.

I want the airplane I am about to board to be flown by a real pilot.

Do you want the plane designed by a brilliant engineer or 100 people who are really good at memorizing engineering questions?

That makes for a snazzy answer but we should probably consider how planes are actually engineered.

Brilliant engineers don’t make safe planes. It’s actually teams with a culture of excellence and quality.

Source: - https://www.netflix.com/title/81272421

This comparison isn't totally valid. Behavioral and system design rounds become much more important in the typical Silicon Valley interview process as you get more senior.

Oh good! We finally moved past the doctor metaphor.

There is no standardized methodology in SE as of 2022 that has anything resembling actual science as it’s basis, or we would certainly have thrown out LC interview hazing by now.

Your comparison is inaccurate. You might as well rail against non-conservatory musicians who taught themselves to play.

For fields where software safety matters, THERE ARE ALREADY EXISTING LEGALLY ENFORCED CODING STANDARDS

I'm not saying that they should be ashamed for being leet coders. I'm just pointing out the inefficiency of the system. It isn't unique to software. Historically, lot of jobs have required irrelevant accomplishments or certifications before employment.

In your opinion, what's the difference between a leetcoder and a real engineer?

In my mind, a real engineer really shines in the non technical aspect of things, like coordination, communication, prioritization, and getting hard questions answered. But that's just me, I'm curious what everyone else's experiences are.

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"

Yeah it sounds like 1x cope.

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.

How many companies have written and still do write their very own IAM solution? Duplicating work and inefficiencies is at the core of modern IT production.