Ask HN: Code examples to find out if a person is addicted to “overengineering”

If it's NodeJS the fastest way is to check how many dependencies they have in total, bad developers will find a way to include 100s or 1000s of dependencies, anonymous third-party blobs of code running within their application:

    $ npm install

Another indicator is how elaborate their build process to munge w/e they wrote into w/e a machine understands.

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.

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.

Ask the person to implement "Hello world" and then count the lines of code, number of classes, inheritance depth, number of external dependencies, etc.

When a candidate solves a programming problem, they typically don't do it with a minimum of abstraction or complication, because employers aren't interested in that. Instead, they'll try and pick something that they want to communicate through the medium of the exercise.

If they choose unit testing, the solution might be over-engineered to be testable at a much finer level than would be necessary in production code, and have more abstractions than usual.

Or the candidate might be trying to communicate some kind of design aesthetic, whether it's familiarity with functional programming, object orientation, design patterns, or some framework du jour that requires a lot of boilerplate. All these will smell a lot like over-engineering on typical toy problems seen in programming problems.

IMO it's very easy to get a mismatch in expectations and presentation in the solution to a programming problem, such that the company and the candidate aren't communicating on the same wavelength. Unambiguous, very simple problems with binary solutions may be better as a basic filter (e.g. Codility or something like it), followed up with pair programming in something more similar to a working environment, where pair communication and direction can get people on the same page.

That's hard to do without some context. They may assume, since they are there for a development interview, that the interviewer wants to see code.