I'm not sure I buy your implicit assertion that other engineering disciplines are somehow better at hiring than the software industry is. As far as I can tell, mechanical and electrical engineers are hired based on relevance of work experience, some discussion of that experience, and maybe a few specific technical details which should be known by anybody with the experience they claim to have. All of which is isomorphic to "Worked at Google, could explain his project in depth, and coded tree inversion on a whiteboard". The only difference I'm aware of is that a Mech or EE would probably be subjected to bullshit situational interviews by HR.
This kind of feels like the general "software isn't rigorous like the real engineering disciplines" angst, which as far as I can tell is also bullshit. In reality, the "rigorous" old-school disciplines still manage to make colossal messes of complex, unprecedented projects, in the same way that software companies often make colossal messes of complex, unprecedented software projects. Sure, civil engineers can build normal roads and bridges and buildings reliably, but then again, software engineers have no problem throwing up CRUD apps and wordpress blogs. There are plenty of bridge collapses, exploding batteries, stalled tunnel-borers, and so on to match all of software's spectacular failures.
It turns out that complicated things are really hard to build, regardless of your field.
Engineering firms won't even talk to someone claiming to be a ME or EE with no degree, no certifications, and/or no license. And, the premise of the article are that they are ignoring both education and experience, so I don't see how your comparison fits.
This thread isn't about who is more likely to fail. We are talking about hiring and who is likely to succeed. My point that companies have dumbed down what they call success so that managers can have jobs has nothing to do with engineering catastrophes. What is being called a success, I call a failure.
> Engineering firms won't even talk to someone claiming to be a ME or EE with no degree, no certifications, and/or no license.
I don't think software is "dumbing down" by ignoring credentials. We're ignoring credentials because we are finding that they have no predictive power whatsoever for competence. Most software companies do still pay attention to experience (at least while sourcing), on the belief that it is not useless as a predictor. This article is interesting because it provides strong data indicating that experience (as presented by the candidate on their resume) is also useless as a predictor.
The point is that people with good resumes are often incompetent, and competent people often have thin resumes. This article presents data indicating that filtering by resume is no better than filtering by coin flip. Thus, if OP's data and analysis are correct, paying heed to credentials and experience is irrational.
> We're ignoring credentials because we are finding that they have no predictive power whatsoever for competence.
I disagree with that actually.
It's my own anecdotal evidence, but from what I've seen, people with degrees write generally better code. They have a better understanding of algorithms, are more aware that what they're writing in a high level language isn't running by magic but is being translated into lower level constructs which may or may not be very efficient, they're more likely to realize there's an existing algorithm for what they're doing, etc.
I guess I would sum it up that people without degrees tend to work harder and not smarter.
The difference between a mechanical engineer and a mechanic is the engineer knows the math. A mechanic can pick up everything about engineering on the job, except the math, and without the math he's crippled.
That's why to be an ME, a degree is a gatekeeper. To get a degree, you have to pass the math classes.
Yes, I know engineers who can't do the math, despite having a degree. I've never known a mechanic to learn the math on the job.
> And, the premise of the article are that they are ignoring both education and experience, so I don't see how your comparison fits.
The premise is not of ignoring them, it's about not elevating them to unreasonable degrees at the filtering stage. In most engineering disciplines, if you have project experience all that matters degree-wise is that you have an accredited one. That it came from MIT instead of Florida Atlantic University might add a couple points, but is otherwise irrelevant. The highlights of your projects get you the initial interview, where you talk details. Then you move to the real technical gauntlet (if there is one).
This industry is different. Too many companies use trivial screening criteria (because resume deluge) and undergrad-level technical quizzes (because fakers) up front, and end up throwing away significant numbers of people they actually want before the process really gets started. This experiment was actually about making the software interview process more like the rest of engineering, with the difference that software as of right now does not require a degree.
This kind of feels like the general "software isn't rigorous like the real engineering disciplines" angst, which as far as I can tell is also bullshit. In reality, the "rigorous" old-school disciplines still manage to make colossal messes of complex, unprecedented projects, in the same way that software companies often make colossal messes of complex, unprecedented software projects. Sure, civil engineers can build normal roads and bridges and buildings reliably, but then again, software engineers have no problem throwing up CRUD apps and wordpress blogs. There are plenty of bridge collapses, exploding batteries, stalled tunnel-borers, and so on to match all of software's spectacular failures.
It turns out that complicated things are really hard to build, regardless of your field.