Hacker News new | past | comments | ask | show | jobs | submit login

It's not overthinking, it's called context.

If you give an engineering problem to an engineer in a corporate environment, he will try to do what he's been told to be a good job: good precision and low cost, complexity not being a problem as far as the solution is achieved. If he's given 1 hour, then using 59 minutes is just as valid as using 5. And rightly so.

As for the numeric problem, same thing. You are not giving a measure of "goodness" and you are not providing rules. I'd go ahead and fill in 2581 = fuck_you , where fuck_you is a constant defined as 3.15. That's a point-wise defined polynomial there. Voila, solved in 3 seconds. Just as valid as making up something as arbitrary as counting loops in a given numeric representation. Also, I'd bet the house I don't own that if I give that in a paper to a kid with no instructions he wouldn't come up with that "solution" - ever.

In the (urban legend) problem about the pen and pencil in zero-gravity, there is context. The objective is to take notes. It's a real world problem with a fixed solution, so yeah, just using a pencil would be a much better solution than engineering a special ballpen. An engineer can and should be expected to solve that. Engineers are expected to solve real world problems and consider real world situations and realistic expectations.




I'm sorry that my article offended you.


It didn't.

When I'm presented bullshit like that IRL I get pissed off, but I can generally take the challenge of pointing out how and why is it bullshit.

Being presented it in HN, it's a good chance to educate more people on why this is NOT thinking out of the box or being clever, and why these are NOT proper tests unless adequate context is provided.


The problem is, if your definition of engineering is solving problems where all the context is fully provided, then 99% of what is interesting on HN isn't engineering. It's apparently bullshit.

Changing the rules and picking a different context are perfectly valid ways of solving a problem.

Squinting hard at real-life patterns and trying to find the rule that generates them is most of the value in business and programming. Ever run an a/b test or looked at analytics and tried to understand why things were changing? The truth is generally as different from what you expect as a number problem whose solution is the shapes of the numerals.


In real life you usually know at least 1 or 2 of these:

- what the problem is

- what you want to achieve

- what the constraints are

- what works (a means to know when you have found a solution)

Without that, you have an undefined riddle and you can try to do something original or clever and see how that goes. Obviously the less you know the less convoluted things will even occur to you.

If you give a bunch of numbers to mathy people they will very likely try some math. They will expect it to be math. That's not loss of creativity, that's reasonable expectations.

In real life, if I'm given a pizza and told to divide it in 11 equal slices I'm pretty sure I can achieve reasonable precision without any measurements. 1/11 is just slightly more than 1/(4*3) which is easy enough to figure out. At most I'd make a few tentative marks before going ahead and cutting it. When you give a problem like this in an interview, you can assume you're expected to prove your relevant skills to the job. In a software company that would be math, algorithms, etc. not just problem solving. If your objective is to get upvoted, then maybe you should try something clever and accessible.


Maybe you were too stupid to solve the problem in a reasonable time?


Took me 3 seconds. Didn't you read the message? :P


I think it's totally relevant, I have worked with guys that have fancy PHD's from MIT that always over complicated the crap out of simple things. It's like when you buy something expensive or make an investment, you feel the need to defend and justify it to others.

It's the same thing here, you get a fancy degree and everything you do has to be complex to justify getting that degree otherwise what separates you from a guy with an average degree. It's probably more an ego thing, but I see this all the time.


I don't understand why you presume it's a need to defend and justify it to others. Getting a PhD from MIT isn't exactly a walk in the park, I imagine the person got it BECAUSE of a pleasure to tackle complicated problems in the first place.

If I really enjoy dealing with complexity and you give me something really simple to do, well I'm gonna go ahead and have some fun with it. It's not a matter of justifying, it's just that simple stuff is boring to somebody who enjoys complexity.


To clarify, I'm not saying over-engineering is a good thing. I'm saying there's a mismatch between the complexity of the problem and the desires/personality of the person having to solve it. Give the simple problem to people who valor elegance, minimalism, simplicity, and keep the MIT PhD for rocket surgery and stuff.


Rocket surgery is a field I dearly want to see created. :-D


This is what happens when you hire someone that's overqualified for a job, I guess. :) People in that situation need to find work that will satisfy their thirst for complexity. They are making trouble for themselves and others, otherwise.


"it's just that simple stuff is boring to somebody who enjoys complexity."

This doesn't work very well with business. Sometimes, you just need the simple solution.

It's also the reason why many startups never get off the ground. I'm guilty of it myself, but I have learned over the years to not over-engineer something until it's really needed.


I agree, but when that's the case then it's right to call it.

Actually, it's one of my greatest pet peeves. How so many things are so massively over-engineered. I could go on forever about that and there is not a single day I don't spend a while realising this about something.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: