Ask the person to implement "Hello world" and then count the lines of code, number of classes, inheritance depth, number of external dependencies, etc.
$ perl -wle "print 'hello world'"
$ echo "hello world"Ask HN: Code examples to find out if a person is addicted to “overengineering”
31–40 of 52 posts
Re: Ask HN: Code examples to find out if a person is addicted to “overengineering”
#32If 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.
Don't agree with the approach because using a proven solution can be superior and net a simpler code base than rolling your own. Fyi, by using webpack, couple loaders, babel, etc I net 100s of dependencies just for the build. Ymmv.
[deleted]
Re: Ask HN: Code examples to find out if a person is addicted to “overengineering”
#33Maybe try asking them what they consider overengineering and ask for some examples of times they've fought against an overengineered solution? Also ask about when code duplication is OK. I can't imagine you can gauge this easily otherwise as e.g. code examples are going to be too artificial but you could probably tell from their answers to the former questions if this is an issue they've thought about before.
Re: Ask HN: Code examples to find out if a person is addicted to “overengineering”
#34I believe "overengineering" will not show itself through code but through time.
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.
Re: Ask HN: Code examples to find out if a person is addicted to “overengineering”
#35I think you need to dig and see what the aspirations of the system were vs what was delivered. The people I've worked with who always went for the complex solution could list off a million "awesome" things that the system was going to do. It rarely did any of them.
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.
Re: Ask HN: Code examples to find out if a person is addicted to “overengineering”
#36Here's an easy challenge: Ask the overengineer to solve problems without introducing any new classes or functions. This starves the overengineer of oxygen, reducing their abstraction options to "loop", "branch", and "add variable". The resulting giant switch statement in a loop is likely to be a relatively clean architecture.
Re: Ask HN: Code examples to find out if a person is addicted to “overengineering”
#37I ask candidates to sketch an API (program, not REST, i.e. an outline of classes, functions and module structure) for a problem similar to those we solve, but smaller in scope. 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,…
Actually, the question is related to employee, not a candidate:) He is working with us quite for a long time, and he writes really good code. But he can't make simple solutions, only the hardest way to solve a problem. And because of it, we can't plan work and estimate tasks.
Well that's a different problem. What is the nature of the work? The first thing that pops in my mind is "perhaps he sees an appropriate level of complexity that isn't accounted for by the other engineers, product owners or other business stakeholders."
Re: Ask HN: Code examples to find out if a person is addicted to “overengineering”
#38If 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.
Don't agree with the approach because using a proven solution can be superior and net a simpler code base than rolling your own. Fyi, by using webpack, couple loaders, babel, etc I net 100s of dependencies just for the build. Ymmv.
I think this is right. I might as how they start the dev environment or kick off a build. Should be something like `yarn start` and `yarn build`.
We all work with really complex systems. The trick is to abstract them to the point where they're simple to understand and use. 1000s of dependencies doesn't even have to be complex at all if you use simple patterns to manage those dependencies.
Re: Ask HN: Code examples to find out if a person is addicted to “overengineering”
#39Have 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…
I don't know if I necessarily agree with this. I'm not necessarily coming at this from the question OP proposed, but from an interviewing standpoint. I've seen a lot of interview questions that didn't necessarily have a real use in reality, so asking the interview _why_ they wanted something implemented can be seen as badgering them and like you might not be a good fit. On the other-hand, if you were to focus your questioning on the implementation, and the interview was fishing for you to question _why_ they wanted something, you may be seen as an someone with a propensity to over-engineer. It's potentially a lose/lose situation.