What's actually in the post: "If you are a Google recruiter, and you want me to interview for SWE or SRE or any role that has an algorithm pop quiz as part of the interview, [...]"
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.
Personally, I think that this whole "oral exam" style of interview is completely wack. If you have a lot of experience with it, then you are likely to do great, and if you don't, then you are likely to suck at it.
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.
The assumption is that, if you were a genius, you'd be able to come up with that eureka spark in the time allotted in the interview.
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).
> 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.
Those were (are?) the designations for certain types of jobs over there. You might think that if you're hired into the company, your possibilities are wide open, but they aren't. System administrator flavored SREs (site reliability engineers) could only get other SA-flavored jobs, of which there are relatively few. Meanwhile, software engineer (SWE) type SREs could go into any other SWE job, of which there are many.
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.
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.