>I think interviewing is just so broken it gives a false impression of quality issues in the labor pool.

I've been in a team where hiring requirements have emerged through the filter of HR almost unrecognisable. Naturally, they're still objective requirements, so qualified candidates are filtered out before ever meeting someone who could judge if they're qualified. It gets noticed, but nothing happens. Of course it doesn't: you're stepping on important toes.

That's how it tends to work. Candidates are filtered out by non-technical staff, including openly using programs that filter out CVs missing keywords. In smaller companies, this even gets farmed out to third-party recruiters that have poorly aligned incentives.

How can we know if candidates are qualified? We never see most of them.

It's hard to imagine many things worse for productivity than bad hiring processes. But it's all just accepted.

> Most problems are solved with time and not cleverness.

Yes, because given time someone clever would have came in and fixed it.

It's like doing push up in the elevator and believing that arriving at the 100th floor is due to doing push ups.

The GE, IBM, Intel, Boeing are few examples that didn't believe in quality - and not just people apparently, and their problems aren't getting solved with time.

Your examples didn't fail due to quality - they failed due to horrible management practices and worshipping at the altar of the MBA philosophy.

They definitely failed due to quality - problems caused by their horrible highly-paid managers and directors.

I worked at GE. A lot of thier software dealing with the transportation industry back then wasn’t technically complicated. There were just a lot of business rules and regulations they had to check for.

My vertical was railroad car repairs

https://public.railinc.com/sites/default/files/documents/CRB...

Most developers aren’t doing “hard things”. Not even at BigTech

It's not at all about doing hard things. It's simply the number of things to be done and how they interact with each other. You are absolutely right that these are technically not hard problems, but they're still hard design problems that keep changing very frequently

Eh, I just don't see it. GE and IBM and Boeing are solving the problems they want to solve. Management dysfunction can't be blamed on low-quality workers. Anyway, I'm a little reluctant to draw the parallel with Boeing because I simply don't know what kind of work goes into that sort of engineering. Maybe cleverness is a big part!

> Yes, because given time someone clever would have came in and fixed it.

I can't emphasize enough how much software engineers overestimate the value of their own cleverness. Bugs are fixed with persistence, in my experience—I've used "cleverness" to find only a handful of bugs across my entire nearly two-decade career. I don't want to say I'm "the best engineer on the team" or anything like that, but I dependably fix the bugs that are put on my plate regardless of how frustrating they are to crack, regardless of what tools I need to bust out to get the job done. Debuggers, printf, valgrind, core dumps, packet captures, profilers, repls, disassembly, whatever's necessary. But all of these take persistence to reach for and use to crack the case. Experience is a short cut, but that's a very different thing than cleverness, and you very directly pay for that experience.

Not to mention if I see "cleverness" in a code review you're gonna bet I'm gonna comment and ask you to make it less clever unless that cleverness seems to neatly solve a problem. Even then, commenting is absolutely critical.

Time, not cleverness, is the key.

Hell, the joke used to be that being a software engineer is 80% googling. Now that barrier's been lowered even further with chatbots: you can literally ask it to find the bug, explain behavior, fix the bug, etc. It doesn't take much competence to correct the output. All it takes is not giving up when you see problems.

Well everything you've written suggest to me that you're clever, or maybe that shouldn't be the word, but somewhere between smart and wise.

And a lot of people aren't that.

I am confused why you included GE. Do you think their aerospace products (jet engines and such) or medical products (MRI machines) are low quality? They are pretty much top three globally in those areas, and very innovative. And how about the Boeing 787? What issues do you have with that?

GE was the granddaddy of the financial engineering shenanigans that have hit the others in the list. If we’re looking for a simple villain, it’s “Chainsaw” Jack Welch.

Screw the company -- sure, maybe they can build a product with mediocre talent. But I don't want to work with mediocre devs, because they make my life harder.

I'd much rather wait for someone I want to work with, than hire the first person that is "good enough".

This is the truth that peoples egos can't seem to handle.

Add in that in the search for the perfect candidate that has all 16 bullet point requirements you'll come across folks who have, say, a solid 13 of them, but they'll get passed over waiting for the perfect candidate to come around. Which can take many months... years even. In the meantime you could have been bringing up one of those 13-point candidates getting them up to speed on those 3 missing bullet points. And you'd likely have gotten to a desired level of productivity faster than by waiting for that perfect candidate while wringing your hands that there just aren't enough qualified people out there.

I don't think anyone is saying wait for the perfect candidate. No one is perfect and no one checks all the boxes. That would be a fool's errand. But most good engineers can differentiate between a good (not superstar) engineer and a mediocre/bad engineer in a couple of conversations. I really have not seen anyone optimize for a mediocre candidate, nor for a superstar. Superstars come by with luck or with tons of incentives (money, stock, tech or whatever is their itch).

I've often seen this happen. A few years back I applied for a job at a startup where I checked a lot of the boxes, but not all, but some of the boxes I checked were difficult to come by - never heard anything back. Six months passed and I was contacted by them, would I be interested in interviewing? I was and I ended up getting the job. Later when I asked about the position being open for so long I was told by one of the people involved that there were folks who were waiting for the perfect candidate to come along and finally, after many months, they were convinced that the perfect candidate probably didn't exist. So yeah, there's at least one instance of it where I know for sure that's what was going on and I've seen others where I'll watch a job listing keep appearing for several months.

So they learned their lesson and hopefully don't make the same mistake again. We are in anecdote land now (both yours and mine), I don't know what's more common. Behavior like that (waiting for long for perfect candidate) can cripple or kill businesses

> I think people seriously overestimate the difference engineer quality makes. Most products can be built with mediocre talent. I'm sorry, that's the truth. We all love to have strong opinions on who we should hire and I say "almost anyone, just throw meat at the problem". Most problems are solved with time and not cleverness.

I'm surprised that your experience here is so different from mine. The best engineers I've had are capable of things that the average to below average ones could likely have never achieved, even with an order of magnitude more time.

I don't think it comes down to cleverness as it does inventiveness. There are dots that great engineers can connect that often nobody else could spot. They also need less process, and a large number of people with all of the coordination overhead does not linearly scale.

Most products can be built with mediocre talent. But no one actively goes after mediocre talent. And yes, startups are more sensitive to this, I really had to let go mediocre people because it affects everything. Throwing meat at the problem for long enough time really screws up the product. Even at a very large company that I worked for, innovation ground to halt after a decade of this thinking, because systems that started simple enough, got complex over time in part because of market and primarily because of mediocrity. Adding things became a nightmare, because we threw meat at problems for a long time.

Maybe what you say has worked for your situations, but it really never worked for me over my experience, and it just was a downward spiral over time every single time.

If workers are mediocre, management needs to be top notch to deliver great products.

If management is mediocre, workers need to be top notch to deliver great products.

The odds you'll land at a place that have both are vanishingly low. It also takes a lot of work, money and interest to turn a big ball of mud around and no one gets a prize for that, people get a prize for churning out features and bugfixes, so this is what you get, specially because most large scale rewrite projects are utter and complete failures.

Each can compensate for the other only to an extent. We don't need top notch, we need good. Most large scale projects may fail, but we ended up assembling good people for all the rewrites. Five of the six projects were successful (in production with objectively better metrics). One failed due to underestimating the operational complexity of a piece of technology.