Why is it a silly question?
Why is it a silly question?
First, it assumes familiarity with golf balls. I have friends who grew up in Manhattan who have never seen a golf ball. They may have seen one on TV, but that doesn't let you really gauge the size of something.
Second, it assumes familiarity with buses, and assumes the interviewer and the interviewee are talking about the same kind of bus. Are we talking about a school bus or a big-city reticulated bus?
Third, it tests skills you're not testing. I live in the city and take the bus all the time, and I don't know whether a bus is 20 feet long or 70 feet long. I'm not good at visually estimating measurements. That might be a skill relevant to a carpenter, but not so much to a programmer. Even if you assume you have the measurements, then you also have to visualize the packing structure of the golf balls. This also tests spatial skills, which are arguably not highly relevant to a programmer.
Brain teasers are generally stupid because they are under formalized. I agree with the poster above. If you want to test logical skills, give someone a section of the logical reasoning section of the LSAT. Those questions were carefully designed to test logical reasoning and to avoid testing other things.
Or, you know, you could always just ask what size a golf ball, and bus is.
It seems to me the only assumption the question makes is that a person could make some logical assumptions about the question, ask some logical questions, or ignore all assumptions and parameterize the answer.
Are they entirely baffled by the question? Are they stuck, with no idea about how to proceed? Or do they ask for more information from the interviewer? Interviews are not about quizzes; they're a discussion. This question is a great way to start a discussion with someone.
"Well, I've never played golf, but I do play squash. So, I'll use a squash ball as a start."
"I have no idea how big a bus is. Let's assume a cuboid of let's say 10 ft by 10 ft by 30 ft."
"Really this question has some sphere packing stuff in there. Being honest, visualising that kind of thing is not my strong point. I'm much better at things like $TOP_THREE_HERE. So, I'll use a weak version first to get a ballpark figure. Let's just line the balls up in a grid (as if each ball is a cube), where each ball touches 6 other balls, or the some other balls and the floor, sides, or roof of the bus."
If anyone is using the question as you've suggested then yes, it's a bad question and they've failed. But you've missed the point of the question.
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.
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.
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.
The issue I have is, if you don't know that when you're asked that question, it's easy for a good candidate to freeze up because they don't know what is really being asked of them. In other words, it's like taking someone off the street and giving them the SATs. Their score is going to suck compared to if they prepared for it. So what you're really doing is testing their ability to take an arbitrary test, or jump through hoops. Since Google prefers advanced degrees, they probably are already pretty good at jumping through hoops, so it's a bit of a pointless exercise that can throw off great candidates completely if they aren't prepared for it.
You can calculate a "valid" response in function of the bus volume and the ball radious f(v,r) without assuming anything and without having any real data.
Off course you can also focus on the "supidity" of the test and that also gives the company an idea of your thinking process and problem solving capabilities.
In any case the test serves its purpose well.
It's an analysis of four things: How an applicant socially responds to ridiculous requests outside their previous experience, and how they handle initiating and architecting a "large" engineering project from a vague request, how mathematically well educated an applicant is, and how wide the knowledge level of the applicant extends (basically a psuedo IQ test, with all the legal risks that implies).
This is vitally important for a handful of positions, but a complete waste of time for most positions, thus silly.