by kristoft on 6/26/17, 6:14 PM with 49 comments
by nostrademons on 6/26/17, 6:43 PM
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.
by swalsh on 6/26/17, 7:40 PM
I'd say the test shouldn't be, how can you find out if they are in the overengineering stage or not. Instead, I'd filter for engineers who can be reasoned with. If you are an engineer in stage 3, it's okay to have a stage 2 engineer on your team, but if he can't take direction then he'll be a liability.
by barrkel on 6/26/17, 6:50 PM
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.
by DelaneyM on 6/26/17, 7:09 PM
> Tell me about the project you are most proud of, which best demonstrates what you're capable of. It could be academic, it could be professional, but be careful to not share any proprietary information from previous employers.
Then I proceed to ask a bunch of code, design, and implementation questions based on that scenario/project. If runtime is important, how they optimized for it; if scaling seems difficult, how they approached that; etc.
Note: This is a varsity-level interviewing question, since you need to be able to quickly come up with meaningful and consistent questions based on their proffered product. It works very well though when interviewing intermediate/senior engineers.
by vonseel on 6/26/17, 6:44 PM
by snorkel on 6/26/17, 6:55 PM
by avar on 6/26/17, 6:48 PM
E.g. "how would you count the number of lines in a file?", "given a regex, please print lines in a file matching the regex", "given N lines, sort them by numeric value" etc.
The most egregious over-engineering I see is someone writing a 100 line Python script for something that could be at most a 100 character shell one-liner with a couple of pipes between different programs.
If they pass that ask them about a problem that would be trivially solved by resisting the urge to reinvent make, a HTTP server, or an SMTP server.
Edit: Re downthread: Yes obviously only in the context of someone expected to know *nix in the case of those examples. But the general approach is very transferable.
Ask the candidate about some trivial problem solvable in 1 minute with standard tooling they use every day, you'd be amazed at the architecture astronauts that come out of the woodworks keen to waste their time on some needlessly over-engineered solution.
by daliwali on 6/26/17, 7:04 PM
The overengineer will introduce a build system, several functional programming utilities, an HTTP client wrapper library, a DOM abstraction library, and maybe a full blown framework.
The competent developer will write a <form> element with inputs.
by age_bronze on 6/26/17, 7:00 PM
by mtdewcmu on 6/26/17, 6:46 PM
by itsdrewmiller on 6/26/17, 7:11 PM
by spinlock on 6/26/17, 7:23 PM
I'd also look for people who are constantly starting from scratch. The complex system builders I've known are _terrible_ at maintaining systems. So, they throw them away every 12 to 18 months and start over. If you think they're complecting too much, ask them how they supported one of their creations over _years_.
Lastly, ask them what customers thought of the result. Look for specifics here. They should give names, use cases, etc... Really, they should understand the business problem their customer needed solved and be able to communicate why the complexity of their solution was necessary to solve the customer's problem.
by sidlls on 6/26/17, 6:59 PM
I also ask about things like test coverage and programming paradigms they have an affinity for. Some things I look for that can be negative signals are:
* Propensity to choose classes and OO programming in a domain it isn't really suited for, or functional/procedural programming where OO might fit better
* Propensity to build for what might be rather than what is (e.g. always have an abstract class even if only one concrete class is necessary)
* Propensity to maximize test coverage (e.g. splitting the logic of functions into smaller ones just to generate test cases, even when those smaller functions are only called at one location) rather than to design for a solution
by westoque on 6/26/17, 7:22 PM
Let me explain, a person thinking through a solution that should only take 1 hour and spends an entire day on it is overengineering. What goes through this persons mind goes something like this: "Maybe solution X is better?", "Is my code good enough?", "What happens in area X?", "Maybe add more tests to cover X?" ...
You get the point. That's why I always focus on the end result and try to be pragmatic as possible. Would this solution be enough to solve this problem, if yes, then move on. Don't get me wrong, performance wise, it should also be taken in consideration but not that it consumes all your time.
by maxxxxx on 6/26/17, 6:51 PM
I often do "cool" stuff only to realize that it was way too complex for the problem. But I make a point to trim it down later.
I would add a step towards the end of the project that focuses on deleting unused stuff and simplifying as much as possible. As always there is no hard type and you often can't predict at the start if something is a good idea or not.
On the flip side people that immediately cry "YAGNI" and never try anything can be a drag too.
by posixplz on 6/26/17, 6:42 PM
Here's a comment of mine, from a month ago, pertaining to interview coding exercises. My example accomplishes the goal you've described, however I'm not sure it's an exact fit for your situation, given the context you've provided. Perhaps some more information about your particular case would help identify good solutions.
by seanwilson on 6/26/17, 7:19 PM
by buzzybee on 6/26/17, 7:24 PM
by 2017throw on 6/26/17, 7:39 PM
by nunez on 6/26/17, 11:39 PM
Because it seems that todo apps are incredibly susceptible to overengineering?
by benologist on 6/26/17, 6:29 PM
$ npm install