> Since it's a question of facts

Is it?

I think it's an opinion.

How would you empirically test if the answer was right or wrong? What's on Wikipedia is also someone's opinion, isn't it? What's in a book that Wikipedia references is again someone's opinion.

If you can't write a program or other set of instructions to test it... it's an opinion.

'How does Dr Foo say that MVC maps to database-server-client?' would be a question of fact though.

Well, it's a matter of definitions. What means it's a completely useless and dumb question, but also that the majoritarian opinion on the relevant context is a fact.

That said, I don't think I've seen MVC used with the same meaning twice... what makes the question even worse.

MVC is like OOP - it means different things to different people in different contexts, and they often contradict each other.

Apple's definition of MVC specifically contradicts the Wikipedia definition for MVC that OP gives.

https://developer.apple.com/library/archive/documentation/Ge...

The current Wikipedia content on multitier vs MVC is quite vague.

https://en.wikipedia.org/wiki/Multitier_architecture

I think "correct" is a reach here.

Stock CRUD multitier should not be confused with MVC, nor vice versa.

A company that doesn't understand the differences is a Red Flag.

That’s entirely reasonable, but people aren’t reasonable. When ego is involved, even a polite argument may appear as a personal attack.

That's entirely reasonable, and that's exactly why you hire engineers that are aware of this, and don't base their choices on ego.

If you hiring involves ego, you're going to end up with a Challenger disaster some time down the road.

I really, really don't want to work for a manager who involves his ego in technical questions.

knowing how many people can't take disagreement well, I don't think this was a poor decision, practically you can't just trust everyone to have a good head on their shoulders, when you just want a job to survive or get your foot in the door, you can't be picky with who you work for.

I think the underlying assumption here, is that it is better for your job prospects to agree with something you know is wrong, in order to avoid confrontation.

I don't think this should be the default recommended advice. It could just as well cost you the job, if you are interviewed by two people, with the other also knowing what his or her colleague said was wrong, and being disappointed you didn't find a way of politely disagreeing.

In job interviews, I would count it as a positive if I could see that the candidate could handle disagreement. That is in my view more important than getting a rather generic technical question "correct".

Behavioral interview questions give you more insight to this e.g. "Tell me about a time when...". In a technical interview you'd be wasting precious time determining how they present arguments. You'd also get false signal from interviewees who are uncomfortable debating their interviewer/know that they need to progress through the question.