You would be astonished, absolutely flabbergasted, at the number of "senior engineers" who interview well, talk great about projects, but cannot demonstrate basic programming skills (e.g., convert an integer to a string representation, or write fizzbuzz).
How does this happen? What (apparently huge) swath of industry am I insulated from where this can take root? Is this just a bunch of wannabes after tech salaries? Or is this is a side-effect of industrial java programming, where their "job" was basically filling in boilerplate? (I am probably unfairly slandering java shops, it seems unlikely, but everything else seems even more unlikely)
I think it usually involves 'helper' type folks. They end up on a project, and they 'help' the project get done. But the work they do tends to be just the boilerplate (or cut-and-paste style work), or just the gathering of test resources, or a surprising amount of work that you would assume that the PM or Manager would do, but instead is done by this person (organizing meetings, setting up checklists, emailing people about current issues/priorities).
This isn't to say that those people don't add value, but if they do this for a few years, they may find that their ability to do greenfield coding has significantly diminished, so much so that they struggle to write objectively simple code because they've fallen out of practice.
Source: I've been one of those people, and I've worked with many. It's an easy rut to fall into, particularly in Test Engineer role (what MS used to call SDET roles).
It boggles my mind too. I've conducted a fair number of interviews both phone and in-person, and I don't think I've ever encountered anyone remotely that bad.
I work in a non-tech company (bank), so I assume the general caliber of candidates is quite lower than what a bonafide Silicon Valley style tech company would see.
Would the typical candidate I interview be able to pass a DS&A leetcode medium or hard, getting the superoptimal solution on the first try within <40 minutes? Probably not. Maybe most of them wouldn't be able to do so on a harder leetcode easy problem either.
But most are still able to code up an acceptable solution to a more "realistic" in-person coding exercise we give them.
There's the concept of the "expert beginner" who works in a role when they're never challenged, so they quickly assume they're great at the thing when from a global perspective, the just stopped learning very quickly.
There's also the type that accidentally falls into a manager-type role way too soon, before they've actually had a proper chance to learn programming well. Then whatever basic skills they had atrophies quickly.
If you assume the top third of candidates only need 2 interviews to get an offer, the middle third need 5, and the bottom third need 15, then 15 / (2 + 5 + 15) = 68% percent of the candidates you interview will be from the bottom third.
This, of course, ignores every human factor but it is a starting point.
I must be one hell of an outlier, then, because of the dozens of people I have interviewed over the years, exactly one could not demonstrate basic programming skills. Most of them couldn't get much further, but that is a different matter.
You are lucky. I end up doing 2-3 screens a week. Ask any of the typical questions were you to google for interviews for Java/Spring/etc.. you get the same canned answers. Push any practical bits, and there are a lot of people who apparently don't know exception handling and some of the other more 'basic' programming things outside of flow control. Few things sadden me more than the senior developer who appears to have done junior coding for years.
You would be astonished, absolutely flabbergasted, at the number of "senior engineers" who interview well, talk great about projects, but cannot demonstrate basic programming skills (e.g., convert an integer to a string representation, or write fizzbuzz).