Comment by josephg

> 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.