Why domain knowledge?

Nobody disputes that domain knowledge matters. You can only choose among approaches you know exist, and you only know they exist by having learned them. The real question is why we train it the way we do, with questions on things that look like trivia. Why should it matter whether you can define the most vexing parse or explain how an OS schedules threads, when you could look it up the moment you need it?

Because the trivia isn't the knowledge, it's the index to it. Knowing that thread scheduling has rules, that a parse can be ambiguous in a specific named way, that a structural problem has a known shape, is what makes those ideas reachable. Without the index, whole categories of solution aren't just hard to find; they're completely invisible. You don't weigh them and reject them, since you never see them at all. The expert's edge isn't speed, it's that more of the solution space is visible to them from the start.

Take the things that feel like trivia until they aren't. Knowing how an OS schedules threads is what turns a service that stalls under load from a week of guessing into "the problem could be lock contention, look there." Knowing what the most vexing parse is turns brace initialization from a rule you follow because you were told to into a fix you understand, which is what tells you when it applies. One is recognizing the problem, while the other is understanding the solution you already use. Both come from knowing specifics about how things work, and without that, the behavior is just weather, something that happens to you that you can only react to.

Which is the real answer to "can't I just ask AI to fix it?" The model can fix the problem you bring it, but you have to recognize there's a problem of that kind to bring. AI can resolve a priority inversion once you've named the stall as one. It can't tell you that's what you're looking at. The person without the so-called "trivia" knowledge doesn't ask the wrong question, they don't even know there's a question to ask, so the facet stays invisible, fixable in principle and untouched in practice.

That's why we have these types of questions. The point isn't to make you recite how the scheduler works, but rather to make the concept fire when you meet it in the wild, so the day a real system behaves a certain way, you already know which shelf to reach for. Look something up once and it evaporates once the problem is resolved, coming back to haunt you another day. Build the index and it's there every time the shape returns.