Yeah, I agree, but not knowing what you don't know applies to almost everyone in every skill, not just programming. I acknowledge I have gaps in my knowledge. But it's because of those gaps that I am always trying to supplement my knowledge by studying different data structures, different patterns for solving problems, different algorithms. I don't aim for complete mastery. I aim for basically "what can I add to my bag of problem solving tools." I concede that because the barrier to entry is low, stories similar to your anecdotes are probably quite common in most self-taught programmers. I think this just speaks to the necessity of rigor during the interview process. Like, does the candidate just know how to build features, or do they know how to design fail-proof systems?
Also, to clarify, I'm not arguing that self-taught vs CS grad is mutually exclusive to smart/not smart. There are plenty of not-smart self-taught engineers and plenty of smart grads.
> In limited domains
I'd argue that many, if not most, teams operate in limited domains.
> I think this just speaks to the necessity of rigor during the interview process.
That gets expensive, fast. There's just so much to cover already, between communication skills, programming skills, debugging skills, architecture / "whiteboarding problems", data structures and algorithms, general problem solving ("interview problems"). A job interview can never be a fully rigorous test of someone's actual skills. Most don't cover even a fraction of that stuff already.
> I'd argue that many, if not most, teams operate in limited domains.
It depends what you consider yourself responsible for. If you think of your job (or your team's job) as shipping features X, Y and Z within this react based web app, then sure - you operate in a limited domain. But if your job is "solve the user's actual problems" then things can get pretty broad, pretty fast. Sometimes you write code. Sometimes you're debugging a hard problem. Or talking to the users. Or identifying and tracking down a performance regression. Or writing an issue for a bug in 3rd party code. Or trawling through MDN to figure out a workaround to some browser nonsense. Or writing reliable tests, or CI/CD systems. And so on.
Its only really junior engineers who have the luxury of a limited scope.
Also, to clarify, I'm not arguing that self-taught vs CS grad is mutually exclusive to smart/not smart. There are plenty of not-smart self-taught engineers and plenty of smart grads.
> In limited domains
I'd argue that many, if not most, teams operate in limited domains.