Or would you prefer the more verbose? The full title of the book is: "How would you move Mount Fuji? - Microsoft's Cult of the Puzzle - How the world's smartest companies select the most creative thinkers".
It's been a very long time since I actually read a real book. And by that I mean, I'll read a printed programming book or listen to an audio book during my work commute. But I must say - it's been ~6 years(!) since I read what the rest of the world would call a real book.

But why break a streak?
On and off for the past year I've participated in the occasional job interview. You may ask "But you seem so happy at GameSpy for these past 5 years - is something wrong?" Nothings wrong per-se, but it's always good to keep your options open ;-)
Let's be clear: I haven't been on that many interviews, but on the few that I have been on - I quickly realized that I would tend to crack at either the puzzle question or some little detail of a programming question and somehow forget everything I know about C/C++. And this is just unacceptable.
Sure - it's stress, but it's that stage-fright stress I never got over. Other than experience of doing repeated interviews or doing a Chippendale's act (a visual that only my wife would appreciate, and cause mental scaring in others) - the only thing that I can do to help is prepare for the puzzle.

You know, maybe I'm not breaking a streak after all? Maybe I'm just reading another manual? Instead of GameAI, Theading, Debugging, or a new programming language - I'm just learning the history, reasons and strategies of geek interviewing.
Yup, that's the sort of light-weight denial/creative accounting that I can live with ;-) It's not a real book - the streak remains UNBROKEN! Whoo-Hooo!

The book was both a slow and fast read. Less than half seems to be dedicated to the actual puzzle Q&A. The rest, of greater or equal value, was mainly comprised of history, the who's & whys of the puzzle - as well as how they can be used poorly.

As you might expect, the longest portion of the book would be reading a question, closing the book, trying to figure out the solution, and then checking how close I came to both the how and why of the answer. The book was actually loads of fun. I must say that the only puzzle that caused me pain had to be the 5 pill bottles with identical looking pills, except 4 have 10g pills and 1 has 9g pills. And unfortunately the digital scale only worked for 1 weighing. It was driving me batty. Then I asked Bren - she spent less than 5 min to realize that you place on the scale 1pill from BottleA, 2 from B, 3 C's, 4 D's and 5 E's. If all were 10g, the scale would read 150g - but it wouldn't, the difference would reflect number of pills from the 9g bottle.
I love that woman of mine - marrying her 10 years ago is still the smartest thing I've ever done.

Now to see if it actually helps on the next interview (whenever that may be). I'll still be nervous, but at least now that I know a bit more about how these cushions should and should not be asked - I may not "flub up" as much as before ;-)

---

you may be surprised to learn that this will not change my preferred method of giving interviews to potential new employees. To me, the most important things are:

• Verifiably interesting resume - and asking questions about it.
• asking fun questions to gage personality. no - I'm not looking for brown nosers that find me funny under all circumstances, that's just weird. I'm interested in finding out how well the applicant will fit into the company culture. Star Trek, sci-fi, current events, ever dream of source code?
• asking for a code sample that has absolutely NOTHING to do with anything we're working on. I like to give them a week or so and to email it to us. I'm interested in the readability of the code, if it compiles, it's length (shorter is better), and if it crashes. I could care less about the "fanciness" of the code. The biggest question I'm looking to have answered: How maintainable is the code by others.