I don't like this kind of interview question because it's all about subjective terminology and superficial knowledge and not about logic or reasoning.
The author is right, the MVC pattern can be considered from many different angles. It's possible to have MVC just on the client side (e.g. with React framework with Redux you have a store as a model, components are views and the router is essentially a controller). React (the library) is itself is also a controller since it handles the DOM diffing and handles the state reactive update mechanism and thus acts as the glue logic between all the views.
I wouldn't want to work for a company with such a rigid view of software development.
It's a sign of seniority when you notice inconsistencies with terminology.
For example, I know some senior developers who had totally different ideas about what is 'unit testing' versus 'integration testing'. Both are valid views because the terminology is still currently ambiguous.
Does unit testing have to only test 1 class in complete isolation (stub out all function calls to dependencies)? Or is it OK to test a class along with its dependencies (no stubbing)? Some developers say that if you include dependencies, then you're testing more than 1 class so it should be called 'integration test', other developers will claim that it's still a unit test with respect to that class - That integration tests must interact with the system from outside via the API (not method calls on a class). Either way, I think that stubbing out dependencies is a bad idea in most cases (aside from mocking I/O calls to external systems like a database) so if I was to accept the definition of a unit test as being without dependencies, then I would very rarely use unit tests... Anyway this shows that even a simple term which is widely known can be the subject of conflicting opinions and it's wrong to criticize people for choosing a definition which doesn't match your own.
Software development doesn't have much global consensus nowadays and part of the problem is that companies are using bad hiring techniques to interview candidates; companies end up forming tribes of like-minded individuals and completely miss all these nuances and these debates.
Its not even superficial knowledge, it's overloaded terminology. MVC as originally formulated came out of Smalltalk and looked more like what we would call MVVM today with smaller controllers. Apple took MVC with iOS and moved it to the opposite extreme with their god-controller objects that knew everything and did everything. Meanwhile what web developers think of as MVC is really the JSP Model-2 architecture where the controller is the entry point to the system which is responsible for coordinating with the models and views to generate a response, where in traditional thick client GUI MVC the view layer is the entry point into the system and the controller sits between the views and the model.
Point being, "What is MVC?" is a very expansive question and I'd be very wary of working for any developer who thought there was one right answer to it.
The author is right, the MVC pattern can be considered from many different angles. It's possible to have MVC just on the client side (e.g. with React framework with Redux you have a store as a model, components are views and the router is essentially a controller). React (the library) is itself is also a controller since it handles the DOM diffing and handles the state reactive update mechanism and thus acts as the glue logic between all the views.
I wouldn't want to work for a company with such a rigid view of software development.
It's a sign of seniority when you notice inconsistencies with terminology.
For example, I know some senior developers who had totally different ideas about what is 'unit testing' versus 'integration testing'. Both are valid views because the terminology is still currently ambiguous.
Does unit testing have to only test 1 class in complete isolation (stub out all function calls to dependencies)? Or is it OK to test a class along with its dependencies (no stubbing)? Some developers say that if you include dependencies, then you're testing more than 1 class so it should be called 'integration test', other developers will claim that it's still a unit test with respect to that class - That integration tests must interact with the system from outside via the API (not method calls on a class). Either way, I think that stubbing out dependencies is a bad idea in most cases (aside from mocking I/O calls to external systems like a database) so if I was to accept the definition of a unit test as being without dependencies, then I would very rarely use unit tests... Anyway this shows that even a simple term which is widely known can be the subject of conflicting opinions and it's wrong to criticize people for choosing a definition which doesn't match your own.
Software development doesn't have much global consensus nowadays and part of the problem is that companies are using bad hiring techniques to interview candidates; companies end up forming tribes of like-minded individuals and completely miss all these nuances and these debates.