I was asked about algorithms for my internal reinterview to transfer from SRE (O ladder) to SWE (T ladder) in 2010. It was the usual sorting algorithm complexity stuff. That's never been my strong suit, and I'm sure I disappointed the interviewer. I sure felt like crap afterwards.
On the other hand, the second interviewer engaged me in practical matters like designing a class which would do some things, and would be thread-safe, and how I'd rig it. Also there was the question of what you could do without a mutex for whatever reason, and when you needed to suck it up and burn the CPU time on it. Then we got into the actual design of a class like Mutex and the helper MutexLock wrapper normally used with it in the depot, and so on, and so forth. I imagine the responses from that individual helped balance out the algorithm drilling I got the day before.
Where are you seeing the "golf balls" question in this post? What you said is true, that it's a crap question, and asking it would probably draw attention to you, but why did you even bring it up? It's like you're blaming the writer for propagating something when it hasn't even been mentioned.
If you were hired on as a SA-SRE as I was, then you have to do an internal interview to get to be a SWE-SRE. If you can't make it through that, you're stuck. I made it, and a friend did too, but I know people who didn't. I'm sure that makes them feel great, especially if they're already doing SWE type work in their daily jobs.
I was told repeatedly there was no difference between the types, but found out the hard way when it was time to transfer from a toxic situation and there were few alternatives. It took over a year to finally get it all sorted out.
When I was in high school, for instance, I was on the math team, and the first year, I got four questions right the entire year! By the time I was a senior, I got four answers right every meet, on average
Did I get smarter between being a sophomore and being a senior? Not at all! I just had a lot more practice of that style of thinking in that particular kind of situation.
This being said, the golf ball question is no more ridiculous than any of the other questions that Google might ask you. That sort of question is designed to see whether you can do a "back of the envelope calculation" that will get you within an order of magnitude of the right answer. Being able to do this sort of calculation is actually an important skill for any kind of engineer to be able to do. I don't think, however, it important skill to be able to do while in one of the most stressful situations you will ever face in life.
Also, I have to take issue with the claim that Google doesn't ask you brain teasers. I interviewed there about three years ago, and I was definitely asked a brain teaser. It was couched as an algorithms question, but it wasn't the sort that you'd see in a typical algorithms class. It was the sort of question where you only come to the answer by having a leap of insight and a light bulb goes on over your head. I.e., this is how all "brain teasers" work. And most "Mathlete" questions, for that matter.
The problem with this sort of question is that if the light bulb doesn't go off in your allotted 20 minutes, then you look like an idiot. And if it does go off, you look like a genius. What if it goes off after 25 minutes when you're in the elevator? Too bad!
You might argue that you can talk it through, but this doesn't usually work for me. To solve this sort of problem, I usually just have to stare at the wall in silence until it comes to me. During the interview, I drew geometric shapes on a piece of paper. The interviewer must of thought that I was stupid. Or as stupid as you can be while wearing a Brass Rat. Until I came up with the right answer at minute 19.5, and then he must have wrote down, "Very smart indeed!" Or at least that's what I imagine, since they did ask me back for another round.
You learned nothing in 2 years of high school? Huh.
The type of questions that they asked at a math meet never exceeded the knowledge contained in Algebra and Geometry, which I had learned by the end of 9th Grade. Mathletic events were designed this way so all high school students could participate on an equal footing.
So, no, I learned nothing during those additional three years that increased my abilities on the math team. The only thing that increased my abilities on the math team was practicing solving the sort of algebra and geometry math brain teasers that they asked at math meets within very limited time constraints.
There's not a math meet problem that I ever saw at one of those math meets that I couldn't have solved on my own given enough time.
I won't discuss whether this assumption is correct or not. But i will discuss that even if you hired such a genius, it would not ultimately make the company any more money, unless you could put such genius to great use rather than grunt work (which a genius would do no better than the grunt - thats why its called grunt work).
They've since stopped, and sadly it looks like Microsoft has taken up the mantle for stupid irrelevant logic questions.
e.g., "3 light bulbs in a room" and "family crossing the bridge" being the classic examples.
You have a family of people of varying weights (the exact numbers you'd have to look up) - determine the optimal way for the family to make it across the bridge.
I had a series of interviews that was all logic questions with a trick that you had to decode to successfully answer it.
It's cute, and everyone gets to feel really proud of themselves if they can solve an applied prisoners dilemma for the answer everyone in the room is looking for, but it's not relevant to the performance of any position that I was being considered.
I'm involved in a lot of interviews and I think the problem is getting worse. Taking all of your questions from a certification exam, constructing a bubble sort, or talking about why manhole covers are circles might be satisfying to a bad interviewer, but does no one a service IMHO.
I'd suggest diving deep into past work experience and ask them to show you something that they have done well so that you can understand the utility that they provide. Very few people that I encounter do this and then try to pound round pegs into square holes.
Truthfully, for a kid coming straight out of college, that's not such a terrible question to ask. (No, I didn't get the job. :P) It allows you to start from a totally neutral knowledge position, and lets you see how a person thinks critically about an unorthodox problem - one they almost certainly haven't seen before.
The problem comes when kids start training for such problems, instead of just tackling the sorts of interesting challenges that would inadvertently cause them to approach this question well...
The LSAT is filled with logic games, and they are nothing like a silly question like, "how many golf balls could you fit on a bus." They are actual logic questions that have a definitive answer that tests your reasoning abilities.
Being good at brain teasers does not make you intelligent; it makes you good at brain teasers. And they don't help prevent Alzheimer's, so they're really just a way for board people to pass time.
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.
Do you think P(intelligent|good at brainteasers) > P(not intelligent|good at brainsteasers)?
I'm not saying it's the best test, most accurate, etc. but if someone is really good at brainteasers I'd post it's more likely than not that they're intelligent. There's probably false negatives with people who are intelligent but bad at brainteasers. But for a filtering test (when Google has too many applicants anyhow) I can see why they're used.