Yes, it generally is. In my experience this is proven by the fact that close to 100% of working engineers are hired that way, and tech industry didn't collapse yet. But if you have better way, that is provably more efficient - I'd be very interested to hear about it (of course, if you're interested to tell me).

Ask any developer if they've ever had the experience of hiring someone who blew them away in an interview and turned out to be either completely ineffective or, worse, slapdash and incompetent on the job. Then, ask how long that poor-fit developer managed to remain on the job before being shown the door.

Or, ask an engineer how many times over the course of their career they've worked with "worthless" teammates, or people who should never have been hired. I've worked across a decent slice of the industry these past 19 years, and from what I can tell, this story is universal.

Another strong piece of evidence on my side is software quality, or the pervasive lack thereof.

Another piece of evidence is fizzbuzz.

Another piece of evidence is the (harmful) trend of demanding that candidates work on a contract-to-permanent basis as part of the recruiting process; what is this other than an attempt at work-sample testing that also happens to exploit candidates and repel the best of them?

I agree with you that close to 100% of working engineers are hired this way. But that doesn't prove anything; it's just as likely, perhaps more likely given the evidence, that what it shows is that development teams can ship marketable software despite terrible inefficiencies.

If you think that conventional hiring does a good job of selecting effective and competent programmers to the median ISV (and note here I'm stipulating ISVs, the best-case scenario for your argument, not line-of-business software teams at F500s), fine. I don't feel like I know a lot of smart engineering managers who are comfortable with the predictive power of their interview systems.