I must admit to hating interviews and especially these sort of questions. I'll happily sit down and chat to people about any of the areas I know about, but these sort of gotcha questions just make me think 'why I am here justifying myself to these people'?
Watch me juggle! Watch me somersault! Watch me do and say pointless things to impress you with how smart I am!
Almost every interview I've ever been on that consisted of these kinds of questions, I've gotten an offer. I agree it's a mostly useless exercise in trying to determine someone's technical skill, but as an interviewee, ultimately it makes more sense to just "play the game" and memorize the mostly-exhaustive list of questions.
Conversely, one interview I do remember where I didn't end up getting an offer, was going swimmingly talking about pirates splitting gold and manhole covers. And then one interviewer asked me with so much Perl experience, why hadn't I published anything on CPAN? Boom, done.
I still haven't published anything on CPAN, but could I interest you in this scale and 8 balls I have here?
I'd answer the question of why I haven't published on CPAN (which I haven't, and I primarily program in Perl for work) is that I don't have the time. I've published some small add-ons for Warhammer Online (Lua, not Perl), and have found that even such a simple thing as that, where it is common for add-on authors to abandon their add-ons and users do not expect much support, was a lot of time. That's because if I put it out there, I'm going to support it. If user's ask for features--even features I won't use--that make sense, I want to try to add them.
If publishing something in such a specialized and restricted universe is so much work, I would expect that publishing and maintaining (to my quality standards) a CPAN module, which would have a potentially much larger audience, would simply take more time than I have available.
My current policy is that unless a piece of code suddenly makes the world a worse place to be in (hopefully I haven't done that yet :) ) I'll release something (normally on my website) and make no further commitment than that.
My philosophy is that it's still better to have your code out there and unsupported where someone can have the option of using it, rather than leaving it stuck on a hard drive never to be seen or useful to the world at large.
While it pains me not to answer every person who emails me about code I put out there, I try to live with it. Plus, it gives them a chance to solve their problem for themselves. :)
In order to get to that point I had to get past the "Oh noes, what if people/future employer/rockstars see my code deride it, laugh in my face and not give me a job because the hacky code I put out is..hacky". I still have flashbacks though. :)
I would encourage you to lower your standards for publishing your code. Is there a "CPAN Unplugged" where lower standards are explicitly accepted and okay?
There are plenty of reasons not to publish on CPAN. Not everyone has time to "babysit" all the modules they write (and deal with people's complaints that they're misnamed, aren't complete enough, etc).
Also, lots of people who were once productive on CPAN years ago have "gone dark" in recent years. Generally has something to do with having a life (fulltime job, family, that sort of thing).
So all in all that's a pretty snarky question to ask. It's definitely a plus to show that you have the sense of civic engagement to go through the full-fledged publishing process on CPAN (including processing testing reports, RT issues, etc) but it should suffice to provide code samples with clean coding style and decent enough documentation (even if it's a well-written README).
Let's discuss architecture of the last app I built in detail, with the how's and why's. Ask me questions on it, rather than just letting me brush through it.
Let's talk about the most challenging bit of code I wrote at the last gig. Get me a terminal and I'll walk you through it. Let's do a "for real" code review--my stuff or yours, either is fine, and get into some meat.
Hell, let's even talk about our feelings.
But these questions in an interview are just not fun. I'm already nervous enough, and getting jostled by missing some stupid trick question that has little relevance just sucks.
Agreed. They may as well just have me take the Mensa test and send them my verified score along with my cover letter and resume, and add that to their initial resume screening. Save us both some time and me some annoyance.
If you are Product Manager for Google's Adwords, how do you plan to market this?
Bad question unless you ascertain the candidate knows enough about Adwords to give a good answer. (Whether a candidate should know enough about your core products is another question...)
What would you say during an AdWords or AdSense product seminar?
Bad question, again requires product knowledge a candidate may not have.
Who are Google's competitors, and how does Google compete with them?
A little broad but could be made into a good question.
Why do you want to join Google?
Waffle question that should be used as filler.
What do you know about Google's product and technology?Have you ever used Google's products? Gmail?
If answer == no/nothing, kick candidate out of room.
What is the most efficient way to sort a million integers?
Poor question but asking general "how would you approach problem X" questions isn't too bad, at Google product managers need to be pretty technical.
How many golf balls can fit in a school bus?
Poor question but estimating similar product-related issues is good and they essentially break down into the same types of answer as golf balls, gas stations in the USA, etc.
How many times a day does a clock’s hands overlap?
Terrible, should never ask something the candidate may have already worked out in the past and which does not require much thought to answer.
The author of "Crack the Coding Interview" and careercup.com claims[1] this list is very, very fake (for "software engineer" questions). She claims to have served on Google's hiring committees for over 3 years, so I would take her word over this blog's author.
In my own experience Google does not ask these types of questions.
If you do your own research on glassdoor.com and other sites where candidates self-report their interviewing experience, you will find almost no reports of candidates for SE positions being asked these types of "brainteasers".
I got asked brainteasers in one of my (many) Google interviews. Non-engineering position though - close to Product Marketing. I was asked to use the board.
Certain interviewers have preferences for certain types of questions. I had questions similar to the listed ones in each category (including basic ones in Engineering).
Generally in their engineering interviews, you're expected to know sorting and search algorithms and their big-O complexity - and expected to code on the board.
First, you only ask one of these silly questions during the interview. And it should be one that makes the candidate sweat and think out loud a lot, but one where they'll eventually be successful -- I like the one where you ask the candidate to think of as many uses as possible for X and you just keep going until they run out of ideas.
As soon as this question is over, the candidate is relieved. This is when you take the opportunity to ask them the key question of the interview, whatever that may be, while they're at their most unguarded.
So watch out for these questions: sometimes the interviewer is just trying to soften you up for the next question.
The same thing happened to me in a GOOG interview. Reading your comment, it just came as a picture in front of my eyes! I succeeded in the first question and gave some brilliant answers until we decided that we spent enough time on that part(aka, i ran out of ideas). I was relieved and we moved on to the next question. I didn't nail that one...no wonder i didn't make it to the next round!
I once had an interviewer suddenly ask me if I liked beer. My first reaction was to quickly guess what kind of answer he was looking for. Obviously, his goal was that to see if I was being honest or just trying to give the right answers. Anyways, I told him I liked beer :)
I understand where you are coming from and I just hate this fake hiring "voodoo" of trying to predict the future of a candidate by asking oh-so-elaborate questions and relying on oh-so-psychologically-awesome tricks.
It probably doesn't have to be repeated here, but most of these are just random apocryphal interview questions - not anything representative of what would actually be asked at Google. There are good sources for actual Google interview questions if you care to look for them.
I have worked through the questions for a software engineering position quite a while back, and while most of the problems were rather boring, there are some quite nice ones in there, for example there is a very simple and nice solution to this one:
Given a Data Structure having first n integers
and next n chars. A = i1 i2 i3 ... iN c1 c2
c3 ... cN. Write an in-place algorithm to rearrange
the elements of the array ass A = i1 c1 i2 c2 ...
iN cN.
I'm surprised, my first big question from them wasn't listed: You have search results coming in from a thousand servers, as a big stream. How do you sort them by Pagerank and send it down to the client? How do you do this on a page-by-page basis? (This was for a software engineering position on the build tools team, about a month ago.)
FYI, I believe interview questions are covered under the NDA, so if you did interview (and presumably had to sign an NDA at the time) you shouldn't actually be talking about the questions you were asked.
I only ever had a phone screen (was going to go for an on-site, but accepted a job elsewhere beforehand) and never signed anything.
Edit: For the record, I really dislike NDAs on interview processes. I signed one when I went for my on-site with Bloomberg a little while back. I would've loved to talk about the process without using vague generalizations, as I think they hit on effectively every bad interviewing technique out there, but alas I can't. I believe they do little to actually help make the hiring process better.
Their NDA does not state that the interview process itself is "confidential". It only states that as a part of the hiring process Google may disclose certain information to the candidate that it considers "confidential", and that you as the receiver are only to use this information for the purpose that Google disclosed it to you (i.e., your hiring).
It would be quite a stretch to interpret this as meaning that the questions asked as a part of the interview, or Google's process itself, is "confidential".
At the rate Google interviews, it'd be quite an effort to make sure that no candidate shared information about their interview questions, the format, etc.
Also, this type of agreement during the hiring process is pretty standard for medium-to-large size companies.
> It would be quite a stretch to interpret this as meaning that the questions asked as a part of the interview, or Google's process itself, is "confidential".
As far as I've heard from anyone here, that's the interpretation. Questions are not to be shared, otherwise we'd spend all our time generating new interview questions and never actually getting any work done.
Sorry, how is that evil? If questions are known they can't be used anymore, and often confidential information can come up in interviews, so it seems only sensible. I don't remember hearing of it ever being used against someone, so it's really just a precaution against someone finding out and then disclosing something really important. I suppose I could have said that not discussing people's questions is only polite, for all the weight it carries.
I understand Google has reasons why they might want to NDA their process, but from the perspective of a potential employee, being asked to sign an NDA for the interview is only a liability. Interviews can be unreasonable (and sometimes even abusive) environments, and I want to know about that before walking into that. Barring that, I want to warn people about bad interview experiences.
If people cannot talk about their interview experiences, there's no opportunity for employers to receive censure for bad interview practices.
Besides, an interview is not the SATs. If this really is the logic for the interview process, then Google interviews are even more broken than I thought.
An NDA would not and could not cover abuse, and I highly doubt it covers your impressions either (e.g. "it was terrible and the interviewers were all rude!"), so I don't really agree with your first point. For your second I can see where you're coming from, although at least in this case I don't see droves of people interviewing and then saying the process was terrible. But there should be (and perhaps is?) an easy way to complain about bad interview practices companies have without running afoul of their NDAs.
For your third point, I don't understand what you're getting at. What logic are you referring to that is broken?
Buy me a beer and I'll tell you the story of my worst interview ever. I'm nice enough to the founder of that company not to name them here, but it was incredibly bad.
In fact, it was so bad I later got a written apology for what happened.
When I interviewed, I was asked exactly one of the given software engineer questions. And a lot that weren't on the list.
Also if you do well on an interview question, a lot of Google interviewers will then choose to dive deeper on the question, and start to ask more difficult follow-up questions.
Anyone who thinks they can memorize a few of these and then breeze through the interview process will have a nasty surprise coming.
>How many piano tuners are there in the entire world?
I can't see how there would be a correlation between answering this question well and being a good Product Manager.
What's most upsetting about this style of question is the 'holier than thou' attitude that comes along with them. If you're not willing to play the game, don't expect to be seen as a good candidate.
This question seems to be pulled straight from the classic 'Fermi estimate' [1]. However I have to say these are actually very useful in quickly assessing options given limited information. I remember doing something like this when discussing a claim about total information produced in history that another person felt was outrageous, I quickly threw together an estimate to show this wasn't outrageous and a physicist friend of mine pointed out the proper term for this. I can certainly see where the ability to do this on the spot would aid a product manager (and in this case I would say the ability to perform this estimate is independent of ever having heard the term 'fermi estimate')
The point of these sorts of questions is not to find people who know how many piano tuners there are in the world, or even to arrive at a reasonable estimate (without good data you're going to be off by miles).
The point is instead to find people who have developed the ability and habit of "back of the envelope" calculation. Not everyone has developed this skill but it can very much elevate the level of many technical discussions. Simply being able to come up with a guess that is within a factor of 2, 10, or even 1,000 (depending on context) can be critically important and impact decisions. Such crude calculations can also serve as the skeleton from which to create more robust calculations with better data. Enrico Fermi was able to estimate the yield of the first ever nuclear bomb test using only his eyes and a few pieces of torn paper blown by the blast, he came within a factor of 2. Sometimes you don't have the most precise measuring instruments or complete data, being able to cope with that and yet come up with useful results is also important.
I can't see how there would be a correlation between answering this question well and being a good Product Manager.
What if there's a product planned that specifically aims at piano tuners? Or a feature change that would affect piano tuners? What if Google Maps wants to add a "Find your local piano tuner" mode? Estimating how many potential users/customers there are, how to reach them and whether it's a significant segment is pretty useful. Sure, the example is bunk but it's meant to be something you have no clue about off the top of your head.
In a country in which people only want boys, every family
continues to have children until they have a boy. If they
have a girl, they have another child. If they have a boy,
they stop. What is the proportion of boys to girls in the
country?
A good analogy for this is flipping a coin. What is the proportion of total heads to total tails if a population of people each flip a coin until they get a heads. The answer is fairly trivial, as each coin flip is independent. Given a fair coin, you would expect the answer to be near 1. You could always calculate the variance given the population size using the binomial distribution.
A more fruitful question might be: what is the average family size in a country with these birthing habits?
If we assume there's an even chance of having a boy or girl, the proportion of boys to girls is still 50/50. It's basic stats. These are independent events.
The companies who buy ad space are served by real salespeople, no? Google product end users for the most case are not Google's customers. Rather, access to end user eyeballs are the product Google sells to the real customers, the advertisers.
Hint: you can use search engines to find job descriptions:
"As an AdWords Associate, your main responsibility will be to manage a portfolio of advertiser accounts. You will be working directly with your advertisers to drive revenue and customer satisfaction."
And of course they have phones. If you were the kind of customer they'd be interested in talking to, you would probably have their number already...
Doesn't it tell something about the interview itself? Canned questions in an interview are at best for filtering really bad candidates, and not that effective there either, precisely because of what you said.
Watch me juggle! Watch me somersault! Watch me do and say pointless things to impress you with how smart I am!