The author describes a YAGNI approach. The interviewer and you seem to want a solution that's already generalized and future proof. YAGNI is always the right approach to take at the beginning of a problem. But that's one of the insights that often come with programming experience and reflection. Unfortunately, seniority is an unreliable indicator for either attribute.

Perhaps one should ask the interviewer whether they want a YAGNI-style solution or a more general/abstract solution. If you can give both, you may really impress the interviewer.

Asking first to understand the needs and intention of the application should be a first step anyhow. Diving into the deep-end face first and coding is rarely the correct approach (except maybe a startup racing for market-share).

> generalized and future proof

Reminds me of a blog post I read,

https://www.sebastiansylvan.com/post/the-perils-of-future-co...

At what point does it become over-engineering?

I think the article captures the problem even better than a similar one that was recently on the frontpage of HN: https://news.ycombinator.com/item?id=17850836

I can't remember a situation where undergeneralized code came back to bite me. I have however seen (and admittedly written some) prematurely generalized code that became messy legacy code.

You often can't tell up-front. If you never get back more than what you put into an abstraction, it was probably over-engineered.

You change the implementation. I think the fear of actually changing already existing code leads to the majority of problems with software development.

That's true. We're not writing code in stone tablets; at any point in time you can just dig in and change what you wrote before. It's infinitely easier if that code is simple, because was written straight to the point, instead of being wrapped in large abstractions.

This should be in requirements. It apparently wasn't in the ones OP was given.

Also, the answer should not be "large dependency injection framework".

Also I would say the answer is better left independent of the runtime environment.

Yes you can load Java classes into the JVM. But why not have a serialization format that is independent of the vagaries and specifities of the JVM?

Still, even if you lean on the JVM, that changes nothing about this particular problem. You don't need command pattern. You don't need a type hierarchy.