Have them build "A framework for X", where X is some commonly-done problem most programmers in their field have worked on (webapps, CMSes, forums, build systems, big data, etc.), ideally related to your business. If you want to do this in an interview or take-home setup, you will likely need to use a cut-down version of this problem, although really, much of the point of it is to see just how much the problem expands.<p>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.<p>An engineer with a propensity toward overengineering will <i>love</i> 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.<p>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.