Because it makes all sorts of assumptions that are outside the scope of what you really want to test.

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.

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.

The desired result is not "X golf balls will fit in a bus" but the process of how the interviewee approaches the problem.

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.

I wouldn't say those are the reasons the questions suck. The idea of asking it is not to get a good answer but to discover the process by which someone would approach an unsolvable or half-solvable problem. In other words, they use it to see how you think through the problem.

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.

It's not a silly question at all. You can completely parameterize the answer in terms of bus volume and golf ball size, or define a "best guess" by explicitly defining your assumptions on the size of a golf ball or a bus in the question. Finally, you should at least be able to provide a magnitude.

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.

It doesn't make assumptions, YOU make assumptions.

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.

Because it could lead to an algorithmic discussion of numerical integration by shells vs numerical integration by disks from integral calculus, a discussion about 1-3 sig fig engineering estimation and error estimation and error propagation, maybe a discussion about circle packing efficiency.

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.