You're correct in that most "good" developers can self-train on whatever stack the employer uses. The problem is that many employers are not even willing to buy one book and wait two weeks. If the candidate cannot be instantly profitable from day 0, they are deemed to be "not qualified" for the position.

There are too many tech fads and trends for a developer to self-train on everything a potential employer could possibly want before knowing exactly what that is.

In my opinion, tech employers should stop being so specific with their requirements and simply allocate some time for the new people to adjust to their in-house way of doing things. As many of us know well, every development team has its own slightly different way of doing things, which has to be learned in order to work more effectively. Nobody "hits the ground running", because the tech skills are hardly ever the limiting factor in hitting full productivity.

And I assure you that any company that wants to hire people to "hit the ground running" will forget to mention their new hires will be doing that running as a steeplechase over mismanagement hurdles.

Training doesn't improve the quality of a candidate. It assures the candidates you can find at the price level you have chosen are familiar with the specific technologies and processes that your company uses.

Then there's a pretty big disconnect that I've seen. The bigger companies that try to hire all the best programmers--Google, Amazon, Microsoft--don't actually care much about tech stacks unless they're hiring for a senior specialist in some specific technology, and even then it'll have more to do with a problem domain than a programming language. The employers who care about tech stacks tend to be either mediocre large companies (who by definition aren't very clueful) or small companies and startups (who really do need you to hit the ground running because they really do have limited resources).

I think it comes down to whether the person directing the hiring process knows anything about programming or not. At large, development-heavy companies, the person hiring may actually have been a 100% software developer at some point, before taking on management responsibilities. Then there is a big doughnut hole, where the company is large enough to need developers, but too small to want to promote any of them, and that is a wide wasteland of frustration before you get down to small companies and start-ups whose business is so strongly focused on tech that they can afford to have a full time developer, but not so much that they can afford a bad one. Those tend to be split between companies that hire for competence and those that want to hire someone that they can use up fast and burn out. If the latter have fewer numbers, they need to hire more people, so their influence in the hiring market is larger.

The mix is very heavily influenced by geographical locale. Around me, the market is mostly the large-but-not-huge companies that hire a lot of software developers but never promote them. So there's my bias. Google, Amazon, Microsoft, et al. do not have a presence here, so they cannot improve the behavior of other companies with their competitive pressure.

I am unemployed because of this.

I worked for too long with Lua, and noone hires a Lua coder, so I am screwed :(

Very few people want to train developers. Essentially, that is the problem in the first place. Employers want educators to provide job training, when that's not what is supposed to happen in higher education.

In the 1990s (and probably earlier), a lot of for-profit educational institutions, in collaboration with a number of large tech companies, produced a lot of "certifications" which tried to fill this gap. It failed pretty miserably for everyone but the for-profit educational institutions.

What's left? Most of the employers want to hire at a lower pay level than most of the qualified applicants are willing to take, especially since regular pay increases have dried up in many markets.

I've been on both sides of this coin, though. I know it's difficult to hire people even if you have plenty of good applicants, because, even when you're willing to train people on the specifics of the position you're hiring them to fill, truly qualified applicants may not work out after 6 months.

In a perfect world (sometimes called "once upon a time"), companies take all of this into account and consider it a part of doing business. In the modern world, companies have found that they can get more work out of their existing employees and out of new-hires by behaving as if all training can be done on-the-job. You might give the new-hires a little less work to compensate for the extra load of learning the job, but the rest of the team has to make sure the job is still getting done AND train the new-hire.

Honestly, the better hiring processes I've seen focus on basic algorithms and data structures as the foundation of judging a candidate's technical ability. That is the stuff you learn in CS. That's also the foundational kind of stuff where, if you don't know it, it doesn't really help if you learn a specific tech stack.

I've also seen C++ shops that quiz you on C++ trivia. Either they were doing a poor job or they were very small and worked only in C++ so it was reasonable for them to ask questions that you'd know the answer to if you just read a book before the interview.

Your post seems to have shifted its goalposts from good to great and back again a couple of times. I would not say that someone becomes great at what they do given only books and practice at home.