Chad Perrin: SOB

11 May 2010

15 Stupid Google Interview Questions

Filed under: Cognition,Geek,Profession — apotheon @ 12:17

Okay, so the title isn’t exactly accurate. They aren’t all stupid. Some of them are actually kind of clever. Others are obviously just designed to see how the interviewee works. Some, however, are definitely stupid.

I ran across an old article at Business Insider: 15 Google Interview Questions That Will Make You Feel Stupid. In short, they did not make me feel stupid. They did, however, make me hope that the smart people at Google are smart enough to not take someone being stumped by a single question as a black mark on their interview, since anyone can be stumped by something that might appear simple in retrospect later.

Without further ado, here are the questions:

How many golf balls can fit in a school bus?

This question is evidently asked of applicants for a product manager position.

The answer is actually really simple. Develop a mathematical expression used to estimate. If they want a more exact number, tell them “Give me a school bus and an effectively unlimited supply of golf balls, and I’ll tell you.” Otherwise, your expression should allow for variable input based on the internal volume of the school bus. You may need to tell the interviewer that you need to look up something about how roughly spherical objects pack together, and you may have to ask whether you’re allowed to grind the golf balls into dust to fit more of them inside the school bus.

How much should you charge to wash all the windows in Seattle?

This question is also evidently asked of applicants for a product manager position.

$50 per window (then pay other people $30 per window to actually do the work). Tell them you want to double-check the market standard rate for window-washing before giving a final answer, though.

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?

This is evidently yet another question asked of applicants for a product manager position, though I think it’s probably a good one for “software engineers”.

It’s time for another simple mathematical expression. This one might benefit from a little recursion. No, I’m not doing your work for you. The end result will, however, be very close to 50% each, with a negligible edge for boys — assuming a 50% gender split for birth rate.

How many piano tuners are there in the entire world?

How many of these target product managers? Here’s another one.

“I need more detail for project requirements. Let’s start with your definition of ‘piano tuner’. For instance — is every person who has ever tuned his own piano a ‘piano tuner’ for purposes of this? If you’re only talking about professionals, tell me how much money the person has to be making to be a ‘piano tuner’. Do we include out-of-work piano tuners? Details, man! I need details.”

That, or: “As many as there needs to be. There may be a few extra, or slightly fewer than there ‘needs’ to be, depending on externalities if people are trying to ‘manage’ the piano tuning economy, or something like that.”

One could always just start doing math based on assumptions of how long it takes to tune a generic “piano”, what constitutes a “piano tuner”, and what percentage of pianos actually get tuned, among other things. Such assumptions will almost certainly lead to inaccurate results, though.

Why are manhole covers round?

Hallelujah, this one is not for product managers. It’s a question for software engineer applicants. Funny how the first “software engineer” question strikes me as a “reverse engineering skills test” question.

If they were square, they might fall through the hole and kill someone working in the sewers.

Design an evacuation plan for San Francisco

Google must hire a lot of product managers. This is another question for such job applicants.

The way I thought of it was this:

“I’d just start working on details and ideas, and let them watch, since I’m sure what they want to see is how I work.” As a friend of mine put it when I posed the question to him, though, “Sure.” Poe-tay-toe, poe-tah-toe.

In any case, a number of questions would have to be asked (or assumptions made) at the start of the planning stage. I’m sure the questions you ask or assumptions you make (if questions other than basic question clarification aren’t allowed) are what they really want out of your “answer”.

How many times a day does a clock’s hands overlap?

Here we go again. Product managers galore.

“22, assuming a twelve hour circular analog clock with an hour hand and a minute hand. Let me know if the requirements differ, or if you want a mathematical expression that can take variable inputs for other clock designs.” The minute hand doesn’t cross the hour hand in the hour leading up to one o’clock, nor in the hour leading up to twelve, but it does cross at twelve. Thus, you have one overlap per hour on the clock, minus one.

Also: s/does/do/

Please make your interview questions grammatically correct.

Explain the significance of “dead beef”

Applicant type: Software engineer! There’s another one that isn’t a product manager.

I have two answers to this:

  1. Dead beef doesn’t fight you as much as live beef when you try to throw it on the grill.

  2. It’s a hexidecimal representation of a fairly big number. If you lop off two of those characters, depending on which pair (assuming you’re counting in twos rather than just picking characters at random), you also get the hexadecimal RGB code for one of several shades of nearly-gray.

The most annoying thing about this question is that they’re probably not really testing your abilities so much as your exposure to certain cultural phenomena — particularly the once-traditional use of 0xDEADBEEF as a test memory address. I’d fire the fucker asking this question of interviewees if that was his reason for asking, or at least ensure that he doesn’t get any say in who’s hired, because letting him keep good people out based on their lack of exposure to this one cultural tradition or let people in based on their exposure to it is a great way to get false positives and negatives in the interviewing process, and thus result in a lower overall value of employee pool.

A man pushed his car to a hotel and lost his fortune. What happened?

This is a question for people applying for a software engineer position.

My first question was “What the heck do these two things have to do with each other?” It occurs to me, after a little thought, that they might be completely unrelated.

You need to check that your friend, Bob, has your correct phone number, but you cannot ask him directly. You must write the question on a card which and give it to Eve who will take the card to Bob and return the answer to you. What must you write on the card, besides the question, to ensure Bob can encode the message so that Eve cannot read your phone number?

This question is evidently asked of applicants for a software engineer position.

First, I’d offer to rewrite the question so the interviewer doesn’t embarrass himself when giving it to other applicants. Then, I’d probably just send Bob a note that said something like “Call me on my cell, or have Eve tell me if you don’t have my number.” It’s not technically a question, but I suspect the interviewer wouldn’t complain. If he would, I probably don’t want to work for him. This is problem solving, not Jeopardy. Anyway, out-of-band confirmation if you’re trying to avoid letting Eve in on the secret seems like the most reasonable answer, so I’m pretty sure I win the prize here.

You’re the captain of a pirate ship and your crew gets to vote on how the gold is divided up. If fewer than half of the pirates agree with you, you die. How do you recommend apportioning the gold in such a way that you get a good share of the booty, but still survive?

This question is evidently asked of engineering manager applicants.

“Figure out how to give everyone exactly even shares — but don’t do it. Now take the money from the shares for a number of crew members equal to half minus two, and spread that money amongst the rest of the crew, so that more than half of them are happy with you. Take the share from the last guy, and put it in your own pot, just for a CEO golden parachute. Since we’re apparently being asshole CEOs about this, follow that up by asking Uncle Sam for TARP funds, then retire.”

The answer they actually want is probably to split the dough evenly amongst the smallest number of crew members that is more than exactly half. That’s slightly safer than my answer, but I think the difference is negligible and if you’re going to be an asshole about it you might as well make out like a bandit.

I wouldn’t give anyone who answered this question this way as if it’s how he actually does his job any kind of management position. Sociopaths need not apply. Nobody who actually believes they should conduct their personnel management duties like this should be let within a hundred miles of an engineer manager position.

You have eight balls all of the same size. 7 of them weigh the same, and one of them weighs slightly more. How can you find the ball that is heavier by using a balance and only two weighings?

This question is (again) for project manager applicants.

Ooh, sorting algorithm stuff.

  • Weigh three of the eight balls on each side of the balance.

    1. If one side is heavier, weigh one of the three on each side of the balance.

      • If one of them is heavier, you win.

      • If they’re the same, it’s the other ball, and you still win.

    2. If neither side is heavier, weigh the other two balls, one on each side of the balance.

      • One of them will be heavier. You win.

No matter how it works out, you’ve only done two weighings. I notice, after writing this answer, that it’s damned near pseudocode already.

You are given 2 eggs. You have access to a 100-story building. Eggs can be very hard or very fragile means it may break if dropped from the first floor or may not even break if dropped from 100th floor. Both eggs are identical. You need to figure out the highest floor of a 100-story building an egg can be dropped without breaking. The question is how many drops you need to make. You are allowed to break 2 eggs in the process.

Get ready for something different: a question for project manager applicants.

I really hope the problems with the clarity and grammar in these questions is a Business Insider problem, and not a Google problem.

This is another sorting algorithm kinda thingie. I’m less certain of this one, off the top of my head. I guess I’d start by dropping one from either the 13th or 14th floor, depending on which I figured would take less time to get to my goal (I’d have to do math for that, or guess based on my mood at the time, and I’m not doing much math today). Then, I’d do something like this:

Given N = (14 or 13) and n = N:
until N > 100,
set N = (current + (n -= 1))

Thus, if we assume N is 14, we drop first from the 14th, then from the 27th, then from the 39th, and so on, until the egg breaks or we get to 100 without it breaking. If it never breaks, our answer is 100. If it breaks, take a step back to the last floor where we dropped it and it didn’t break and start going up one floor at a time until the second egg breaks. Intuitively, I’d say that with either 13 or 14 as the starting value we shouldn’t end up with more than about 15 tries before we figure out which floor, and we’d end up breaking either two eggs total or no eggs. I think.

Explain a database in three sentences to your eight-year-old nephew.

Why does a product manager need to explain a database to his eight year old nephew?

“Say you have a bunch of checkerboards and a crapton of checkers, each of which has a different piece of information on it, and you store your checkers with their information in the squares of the checkerboards. Each board is sort of a categorical topic area, with each column and row corresponding to a value type so that when you combine the value types you get unique values that correspond to each piece of information. There, I did it in two.”

Yes, any eight year old nephew of mine that would get my explanation of a database would be pretty smart. If he was dumb, I’d say “It’s like a well-organized bucket that you fill up with things you know.”

Note that nobody said it had to be a relational database, and I went beyond the call of duty assuming it was a technical implementation of a database as one uses with a DBMS anyway so that there’d be something to explain (otherwise it really is just a bucket of information).

I’m sorry. This is really just an incredibly stupid question. Maybe I should have used one sentence: “Here’s the URL for the Wikipedia page for ‘database’.” Yes, a question that tests one’s ability to explain technical things in simple terms can be very important, but there’s not nearly enough context here to actually give an answer that will suit the needs of whatever scenario the interviewer has in his head.

You are shrunk to the height of a nickel and your mass is proportionally reduced so as to maintain your original density. You are then thrown into an empty glass blender. The blades will start moving in 60 seconds. What do you do?

What do questions like this have to do with being a product manager?

Considering the dimensions I’d have at that point, I might just try lying down and letting the blades whir over my head. I’d hold on tight for good measure. This is assuming I couldn’t disable the blender, of course. This is a terrible question. Maybe they’d be happy with the answer “fire the guy who shrank me and put me in the blender, and get his replacement to get me out,” since this question is so stupid.

The Rest of the Story

I looked at the provided answers after I wrote the rest of this SOB entry. The answer to the question about the guy pushing the car is an even stupider, more culturally dependent answer than the thing about dead beef, and if getting hired depends on the answer to that, there’s something deeply fucking wrong in Google’s hiring process. Seriously. What if I pushed my wookie, instead of my car? Maybe I’m playing the Star Wars Edition, numbnuts.

Before the list of fifteen questions from Google interviews that are supposed to make you feel stupid, the Business Insider article offered three criteria for getting hired at Google that have nothing to do with these questions:

  • Google prefers Ivy Leaguers.
  • It cares about your GPA, even if you’re in your 30s.
  • It wants people who want to change the world.

I’m okay with the last item in that list, but the first two are ridiculous. Seriously? This is another case of that tendency hiring managers and HR people have to believe that something that narrows the field is good even if it doesn’t actually test for something particularly relevant to job performance. Sure, a higher GPA may correspond to a slightly higher tendency toward good job performance, but by throwing out anyone whose GPA sucked (or may not have attended college at all), you may be ignoring a completely different, more directly relevant metric that could have a much more important and reliable impact on your ability to hire the very best. Don’t even get me started on the Ivy League school preference. Remember that correlation does not imply causation, and you’ll avoid these asinine mistakes that major corporations all seem dead-set on making.

I’m also not sure the last item on the list has led to good things. How exactly do these people want to change the world? Judging by Google’s performance, this requirement has resulted in better-than-average outcomes for the “don’t be evil” motto, and for the corporation’s success, but “better-than-average” for a major tech corporation isn’t saying much when you’re comparing it against examples like Microsoft and Oracle. If average is somewhere south of -85% on the Goodness Scale, I don’t think a “better-than-average” result of -80% is a “good” outcome. Maybe Google should change that motto to “Don’t be as evil as Microsoft.” At least then it’ll probably correlate more strongly with results.

29 March 2010

another writing gig

Filed under: Geek,RPG,Writing — apotheon @ 10:45

In addition to being the primary name on TechRepublic’s IT Security column, I have another (semi-)regular writing gig now. I’m not on an actual schedule at Troll in the Corner, but the idea is for me to write as close to once a week there as I can reasonably manage amidst the rest of the doings in my already overburdened schedule.

As of today, my first article at Troll in the Corner has been published: Finding Inspiration for NPC Concepts. Hopefully you’ll like it as much as the enthusiastic first commenter did.

I have vague plans in mind about topics for other articles soon, including a stat block and description for a new critter, some stats and background for NPCs in support of a module, and maybe an overview of what niche Pathfinder RPG fills.

I’ve been kicking around the idea of starting up an RPG-focused Weblog of my own, but I don’t think I’d get around to it any time soon, and might not maintain any kind of writing schedule at all, so a gig writing for someone else will probably prompt me to write more often and has already prompted me to start writing much sooner than I probably otherwise would have started writing. So . . . there.

4 February 2010

Documentation Documentation

Filed under: Geek — apotheon @ 01:21

No, the title of this is not two thirds of a joke about Steve Ballmer’s “Developers Developers Developers” dance. I’m talking about documentation for documentation.

The Set-Up

There are at least two types of open source development projects in the world.

  1. There’s the fakey-type open source development project, where someone writes code in a closed team (perhaps a team of one) and makes that code available to the world under an open source license, but there isn’t really any way for anyone to actually contribute to the project.

  2. There’s the for-realsies type of open source development project, where anyone can contribute — though contributions may of course be rejected if they aren’t “good” (by whatever definition the core team uses to use).

The Documentation

It’s a pretty generally accepted truism that documentation is important. People argue about whether their pet projects have good documentation, what constitutes good documentation, and so on, but they tend to agree that documentation is important.

A key part of most open source development projects is openness about accepting contributions to documentation. Accepting documentation contributions can help improve documentation without taking time away from actual coding by the core team. This is a good thing.

The Problem

It is often the case that there is a very clear-cut, easy way to contribute code to a project, but someone who wants to contribute documentation is left wondering “What the hell?”

The Solution

If you run a Type 2 (“for-realsies”) open source development project, stop right now and look at the documentation your project has for documentation. How well documented is the procedure for contributing improvements to documentation? How easy is it to find?

Seriously, this should be one of your top priorities when running an open source project that actually wants contributions from the user base. If you have a core development team, it is actually more important, most of the time, to encourage documentation contributions from the general public than code contributions. The only time code contributions should take precedence is when you no longer have anybody (competent) on the core team.

If you don’t have clear, useful, fairly complete documentation documentation (that is, documentation for the process and standards of creating and contributing acceptable documentation improvements), start working on it now. Please.


« Newer PostsOlder Posts »

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License