Agreed, and let me offer an anecdotal, real-world example. Before I was in this racket, I used to be a land surveyor. Because it's both technical and licensed (and btw, I'm not going to make an argument for licensure, just mentioning it as a qualifier), you had to take a written test and pass a rigorous interview before you were accepted as an apprentice land surveyor. The test involved trigonometry, plane geometry, algebra, property law, and basic statistics. The sit down involved attempts to surface red flags all the way down to testing if the candidate was afraid of dogs.
And after passing that, then you were hired on as an apprentice which meant that all your work had to be reviewed and signed off on by a licensed PLS while you learned on the job and could eventually take the PLS exam yourself.
Too often in software engineering, a candidate can jump through the hoops and get hired but even if their role is junior, they're essentially on their own except for code reviews. There's very little mentoring, because senior people are neck deep in work and nobody's got time for that. The company has to be committed to mentoring and carve out space and money for it in order for it to happen.
We would be much better off if the craft of programming was treated like other trades, requiring training and formal apprenticeships, with the necessary mentoring and signoff.
Programming is to CS as plumbing is to fluid dynamics. Knowing how to write a bubble sort is an irrelevant skill.
Knowing how to use the standard library in the environment is much more relevant.
It takes much longer than people assume to get a dysfunctional team member off the payroll. In most shops, new hires spend months in a (reasonable!) reduced-expectation state of on-boarding and ramping up, during which their performance can't readily be measured. It then takes several engineering cycles to figure out that they're not working out on a particular project, after which the normal response is often to try moving them to another project. You can be more than 6 months in with an employee before there's a confident assessment in engineering management that someone isn't working out. In many shops, at that point the next step is to begin the process of "managing them out" (often with multiple stages of PIPs), which includes a fig-leaf premise that performance can be fixed and the team member retained.
And that's if things are carefully managed. Lots of teams, even good teams, aren't carefully managed, and it can take more than a year to detect and propagate the signal that someone isn't working out.
The net result is that people can accumulate impressive-looking resumes without ever effectively delivering for any team, and because resumes get more impressive over time, the roles people get offered improve as well, compounding the effect.
I'm an evangelist for evidence-based hiring techniques and a fierce critic of standard interviewing practices, which I agree are dehumanizing and unreliable. But we started our hiring practice[1] not because we wanted to include more people, though that was a happy result of it, but rather because we'd been burned repeatedly by good resumes and strong interviewing skills.
At this point in my career, for a technical/IC role (really, any role), I'd be alarmed if I wasn't given practical tests to verify I can actually back up my talk. Their absence would make me suspicious (though perhaps not dispositively so) about the technical ability of the team I was considering joining.
[1]: https://sockpuppet.org/blog/2015/03/06/the-hiring-post/