An engineer who doesn't overengineer will first ask a lot of questions about why you need X, and then will build X, and then only after you have tweaked the problem requirements will generalize that into a framework. They are likely to think this is a bad interview question, which it is, and push back to get the actual concrete requirements. That's exactly what you want; overengineering happens when people guess at the requirements instead of making sure of them.

An engineer with a propensity toward overengineering will love this question, and immediately jump into all the features their framework will support. They'll carefully get lost in thought brainstorming new features that might be cool, but when it comes time to implementing it, they'll either completely fail to reconcile all the contradictions that have crept into the design, or they will come up with a very complicated mess that does everything but trades off unspoken requirements (like performance or simplicity) for them.

This mirrors how frameworks actually work in the real world: basically every framework that people actually use was extracted out of a working app that solved one problem well, while every framework designed from scratch is an overengineered mess.