Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Generally speaking, when questions like these are asked (I used to work somewhere that did them, and was often responsible for evaluating the responses), nobody cares that you come up with the right answer.

Rather, I should specify, the right answer looks like this: Let's say a golf ball is approximately 2 inches in diameter, and let's say that the bus is approximately 20 feet long on the interior, with seat backs that are approximately 6 inches thick, seats that are approximately 8 inches thick, sit 18 inches off the floor, and are supported with posts of approximately 1.5 inches diameter.

The key is in being able to break down a problem, identify the challenges (seats are wonky shaped, for example), identify all the components of the problem (e.g., seats take up space, seat posts take up space, buses aren't perfect rectangles, etc.) and all that.

For what it's worth, I've evaluated that question more than a few times during interviews, and I have absolutely zero idea how many golf balls you can fit into a bus. If you don't know what kind of bus, ask. If you don't know the dimensions, ask.

If you're going to throw up your hands and claim that the problem is unsolvable (plenty of people do, some even got hired), then perhaps a job in solving problems with possibly unforeseeable parameters isn't the job you want.

There are plenty of other problems with the question, sure, but the key is in being able to figure out what the parameters are, at least loosely define them, and come up with a strategy for working the problem out. In the best answer I ever got, the guy asked to borrow the whiteboard and started charting out equations to calculate it (with variables such that if he was off on the diameter of the golf ball, you could replace it with the correct value and re-run the calculation). I stopped him well before he got anywhere close to actually solving the problem and recommended he be hired.

Of note, I do not now nor have I ever worked for Google, so I can't say how they perform those, if it is even true that they did, but that's how I've always approached them.



The problem is that people who aren't familiar with golf balls, etc, might be so put off by the question it impairs their ability to think through the problem. You're biasing the question against specific groups of people, on criteria that are completely irrelevant to the job.

I used ask "can you break down the problem" questions all the time. I'd base them on programming tasks. Because, you know, I was interviewing programmers.


That's a fair critique, and pretty much what I said the first time I was asked to join the interviews to evaluate the answers.

Regardless, I do believe that being able to ask "how big is a golf ball" when you don't know is a crucial skill to possess, and I've found (anecdotally) that the people who threw their hands up, but were hired anyway, generally had poorer work performance because they either didn't know how to ask for help, or weren't willing to admit that they didn't know something.

Humility is a very good skill for any programmer I think.




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

Search: