What I don't understand is that this report seems to contradict other reports of software engineers being in high-demand, which presumably should lead to lower interview barriers?!
It's a market for lemons. When devs are in demand, that brings in applicants who are only in the industry because the wages went up, while the good ones are more likely to be taken. These each lead to a greater proportion of incompetents to filter out, and the cost and risk of accidentally hiring one have not improved.
What risk though? Instead of these days-long interviews with multiple people (and the inevitable meetings after to discuss their results) why not just hire people provisionally and see how they do? Especially if you pair-program, code review, or anything that will expose them to evaluation.
I'd advertise with something like "Job coding X at a company that does Y. Finish the Ruby Metakoans and be prepared to discuss your answer. You will be asked to code in Ruby and C during the interview."
These huge processes just seem like HR trying to justify their existence.
After a phone screen, we spend maybe five hours of developers' time on each candidate and reject 80–90% of them. If we provisionally hired all of them expecting useful work, we would invest far more time ramping them up on our system, risk outages from their early mistakes, disclose trade secrets to a bunch of devs who end up unhappy with us, and lose out on all the employed candidates up front (who aren't going to quit just for an extended interview).
Then there's the moral hazard of paying anyone who can get into our filter, rather than just the ones who can get all the way through it. It's the same reason we can't expect candidates to compensate us for the cost of interviewing them—it's better if a bad match is lose/lose than if anyone could reliably expect to be rewarded for wasting everyone else's time.
I wasn't suggesting you hire everyone who walks through the door, but I bet my hour-long test is within 80% as accurate as those crazy all-day stress tests, and much cheaper. Asking for code (even a few lines) in the application itself would further reduce the number of applicants.
Your system/circumstances seem like they'd make trusting and benefiting from new hires quite a hassle. Ideally you'd have some public and open-source app to have new hires hack at, but there should be tests to be written, etc, which shouldn't leak trade secrets. (If you don't have docs for which files/components implement your trade secrets, and therefore which ones do not, I don't see how you have any hope of keeping anything straight.) If their early mistakes cause an outage I think it says more about your build processes than them.
As for people not quitting for what's in essence an extended interview, that's what they are doing for you and others already. You fully intend to dump them if they don't prove to be good, but you don't have a quick process to determine this so you aren't as up-front about it.
But yes, not every place has it as easy as Github, for instance. They have a ton of publicly available code an applicant could work on, and in doing so they'd show they could use the company's products and tools. I don't know, but would bet they have a comparatively easy interview process.
