There are a limited number of known failure modes when working with physical materials. We know the properties of materials and we know the physics.

The equivalent to fizzbuzz would be something like a free body diagram.

The engineer building the bridge is liable. Hence, you get engineers with qualifications (instead of a random person with X years in Y), and those qualifications certify they know what they are doing.

Which in my opinion brings up the certification argument, but I, as I’m sure others, have found that most certifications mean nothing in regards to whether someone can actually do the job. Is the key component missing in hiring in our industry a vastly more rigorous/extensive/difficult testing and certification protocol?

I'm an engineer in physical disciplines, and I don't think it's a certification issue. It's more that "engineering" in the software world is conflated with craftsmanship. The word "engineering" as used in relation to software is basically interchangeable with "technical work". Let me hasten to add, this is not intended to be pejorative or haughty, rather an observation.

Whether it's bridges, aircraft, or other complex engineered systems outside of software, there is a fundamental commitment to correctness, as assessed against physical principles such as conservation laws and both high-level and low-level verification criteria. Some software orgs (I think mostly in safety-critical systems) apply this kind of rigor, but most software development does not. Just look at the pushback on this site for development systems that increase rigor at the expense of "development velocity", such as memory-safe languages, powerful type systems, formal methods, etc. No civil engineer is going to be OK "shipping" their product without stress analyses, material property knockdowns, and the like.

My suspicion is that the root of this lies in an inability to systematically reason about software the same way we can about physical systems today. The tools and principles for correct-by-construction software are more primitive and harder to use than their equivalents in the physical realm. Also, lack of rigor in software still gets you a lot of powerful software and society seems remarkably tolerant of shitty software outcomes.

All software doesn't need to be engineered, the same way no one engineers a hand-crafted piece of furniture. But our software infrastructure ought to be, and it surely is not today. It will be awesome when software engineering starts living up to its billing, as I hope it one day does.

Yes, and in other engineering disciplines this level of rigor does exist. https://en.wikipedia.org/wiki/Engineer_in_Training

which is why bridges and buildings certified by qualified engineers have never collapsed

Both types of structures have collapsed.

I'm pretty sure someguydave was being sarcastic.

indeed.

I don’t believe any particular test or qualification wards off mistakes

I guess, that person is just being sarcastic. However besides certification, qualification etc I think huge factor is cost of IT project is variable. And even worst failures are mainly delays, extra budget or moving work to different vendor/product. So companies can save money without endangering lives.

A bridge, even a fancy modern one, is pretty simple compared with the software running on a 90s-era computer, much less a modern computer. Fizzbuzz is probably about equivalent to building a simple engine out of a box of parts.