Alex Staveley is a software professional passionate about software engineering and technical architecture. He blogs about architectural approaches, Java topics, web solutions and various technical bits and pieces. Alex is a DZone MVB and is not an employee of DZone and has posted 48 posts at DZone. You can read more from them at their website. View Full User Profile

Book review: 'Are You Smart Enough to Work at Google?'

  • submit to reddit

You need to toss a coin for a football match. The only coin you have is bent and biased towards one outcome. How do you use the coin and ensure a fair toss?

I love a good a puzzle and there are certainty plenty of thought provoking mind benders in this book - most of which I had not heard before. Author William Poundstone (author of 'How Would You Move Mount Fuji' and 'Fortune's Formula') describes various puzzles that are describes various puzzles that are likely to be part of a Google interview process - that company now estimated to be running over one billion search requests per day!  Some other aspects of Google are covered, but the subject matter is predominately puzzles - all types of puzzles: fermi questions, deductive logic, numeracy skill, algorithmic questions and some grade A counter intuitive mind boggling teasers!

William Poundstone
One can't help asking the question why Google bothers with all of this?  Surely, the point of an interview is to see if someone can do a certain type of work and the interview should be a fair attempt to assess a candidate's suitability. I have had the fortune (some would say misfortune) to be part of world of Software engineering for the last 15 years.  I am passionate about it, but I'll be the first to admit it isn't just about solving fun puzzles. Following best practises, following agreed processes, keeping up to speed with technology, documenting solutions so others can see what's going on are all very important things to make a good software engineer.  And it's not always sexy work.  Sometimes it requires patience  debugging ugly code while sticking to a tight project deadline. Ascertaining how good someone is at all this in an interview setting can be difficult - especially when it's very easy for a good candidate to freeze from nerves or get an unexpected mental block.  It's very difficult to objectify what makes a good software engineer. Sometimes someone very intelligent can get hung up on abstractions or theoritical patterns and forget they have deadlines or just not be a good team player.  Sometimes, there's just inescapable subjectivity.

Joel Spolksy
So how do brain teasers help out? Acclaimed tech guru, Joel Spolsky advises to avoid asking them in interviews because they are usually just a case of either the candidate knows it or he doesn't - and not much else.  In my opinion, it can take months to understand someone's technical strengths and weaknesses.  Puzzles can be useful for demostrating how someone approaches problem solving, how they think on their feet and how they communicate ideas.  So yes they do serve a purpose.  But even if they serve no purpose whatsoever other than a bit of fun, that's fine for me.  I love a good puzzle so I really enjoyed this book and for that reason I'd recommend it to anyone who likes to dabble in some cryptic challenges.
Published at DZone with permission of Alex Staveley, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Jean-Baptiste Nizet replied on Fri, 2012/06/01 - 9:33am

You need to toss a coin for a football match. The only coin you have is bent and biased towards one outcome. How do you use the coin and ensure a fair toss?

My take: you hide the coin in one of your hands behind your back and ask which hand holds the coin. 

 Am I hired?

Francis Perreault replied on Fri, 2012/06/01 - 10:58am in response to: Jean-Baptiste Nizet

Well, technically, you have to toss the coin, so how about not telling the teams which side is biased? It could even be a coin with identical sides... The odds of a team picking one side over the other is the same, as long as no one knows about it before the toss...

Peter Levart replied on Sat, 2012/06/02 - 11:32am

My take:

You toss the coin multiple times until the outcome of two consecutive tosses is different. Then you take the outcome of the last toss as the deciding outcome. 

Nick Maiorano replied on Sat, 2012/06/02 - 3:26pm

While these responses are certainly creative, they don't actually solve the problem of using the coin to ensure a fair outcome. The solution is very simple: you have to use odds, just like at the race track, to compensate for the fact the 2 sides of the coin don't have an equal chance in the coin toss. If, for example, heads has been determined to come out of 3 of every 4 tosses, then you must toss the coin 4 times. If 3 or more tosses result in heads, then heads wins otherwise tails is the winner. It's a boring but effective solution - just like good software ought to be. 

Peter Levart replied on Wed, 2012/06/06 - 3:23pm in response to: Nick Maiorano


What do you do if "for example, heads has been determined to come out 2 of every Pi tosses" ?


Nick Maiorano replied on Wed, 2012/06/06 - 8:23pm in response to: Peter Levart

...Then you would need to toss the coin Pi times and get 2 or more heads to win. ;-)

Jaime Martin replied on Wed, 2012/08/29 - 7:45pm

Peter is correct as long as you toss the coin in pairs - otherwise you are just reversing the odds.

When thrown in pairs the probability of a head followed by tails is equal to the probability of tails followed by a head.

Nick's idea was my first thought but a football game has to be played so we have no time for the amount of trials needed to detrmine the bias.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.