I've been trying to hire sysadmins for my team recently, and sit next to someone trying to hire senior engineers for our infrastructure team.

Candidates for my team first get screened by recruiters, then have a couple of phone calls with HR and the hiring manager, and then if they sound good are sent to me for a technical screen. I give them a fairly simple scenario with extremely clear symptoms, and all I'm looking for is very basic problem-solving skills. I want to see the candidate come up with a theory about the problem, then try to prove or disprove it, or any attempt to narrow down the problem space. The majority of candidates, even those claiming two decades of linux sysadmin experience, appear to have basically zero troubleshooting skills, just keep repeating cargo-culted "restart things" rituals, repeatedly keep checking things that are already ruled out by the symptoms and all their previous steps, and sometimes get angry and defensive when I claim that their "solution" wouldn't fix the problem, or claim that they'd see certain behaviour in the scenario. I would not trust these people to find their way out of a wet paper bag without a "runbook" containing that exact scenario, down to the color of paper and precise moisture level.

This problem is not exclusive to senior engineers. Even trying to actually hire someone just to follow directions is very hard. A while back, we wanted to hire a contractor to do a few hundred hardware upgrades in our data center, along with a few other tasks, all very repetitive and well-documented, so I printed out our documentation for adding a new server to our asset database, set up a copy of our asset database on a spare laptop, and brought it in to the interviews I did with those candidates along with a server, and my entire interview was just "Follow these written directions, exactly as written; this is literally one of the tasks we want to hire you to do." Only one candidate out of five was able to complete it successfully, and all the others just had an endless string of questions that were clearly answered right in the document. For example, the document would say "asset_serial: this number should be on a sticker on back of machine.", and they'd apparently just skip over it, get to a later part that wants a serial number, and ask "Where's the serial number? I don't know what to enter here." They somehow didn't start reading any more closely after forty five minutes of me saying "That's answered in the document; please read it more carefully." repeatedly.

My colleague who's been trying to hire for a senior engineering position has been doing one-hour phone screens with an extremely simple text processing programming challenge, "Given text like this with numbers like that, give me this aggregate summary of the numbers", to be solved in any way you like, with any resources you like. Almost all candidates, including those who claim multiple decades of programming experience, fail to get anything that works. Every candidate we've had so far who chose to write a solution in C++ hasn't even produced a program that compiles successfully. Just to make sure we're not completely miscalibrated, we've had engineers already employed here try it, and they universally got a working solution in about ten minutes or less.

When you're trying to hire, the vast majority of applicants will be terrible, because nobody wants to hire the terrible people, so they vomit applications across every company they can possibly find, and continue to do so for long periods of time, where the high-quality engineers usually find a job through professional networking without ever trying to come in through the front door, or very quickly get and accept offers and so are on the job market for a very short time.