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

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.




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

Search: