I am the ghost of groovymother.com. Woooooo!

The book that is indirectly responsible for me getting my new job

A few months ago, I was in the pub with a couple of geekchums. The topic of job interviews was going round the table, in part because I’d been talking about my goal of getting a job and moving to the Bay Area. Someone mentioned that they’d interviewed at Google, had read Programming Interviews Exposed the night before the interview, and nearly every question they’d been asked was pretty much out of the book.

This caught my attention, because a few months earlier I’d had a phone interview with a division of Google that rhymes with TouYube which had gone pretty well until they pulled out one of those algorithmic questions that Google loves; Something about finding the median value in two sorted lists of integers. I’d come up with a solution, but clearly not a satisfactory solution. (As Keith later described it, every Google interview question has to have an O(log n) solution… and at that time, Big O notation hadn’t been on my radar in freakin’ years). The next day, the recruiter called to say they’d decided to pass on me.

So, the morning after the discussion, once the hangover had subsided, I ordered myself a copy. I read the whole thing in a few days, absorbing details about graph theory, pointers, recursion and, oh yes, Big O notation that I hadn’t thought about since receiving my CompSci degree 10 years ago.

But more important were the example interview questions throughout the book. Generally these would be structured as the question, followed by a naïve solution, a better solution, and then any follow-up questions or limitations the interviewer might introduce. For example, if you get the classic “Reverse the order of words in a string” question, it guides you through the initial solution of “Start at the end of the string, scan backwards, and when you find whitespace, copy the word to a temporary buffer, then replace the original string with the new one”, then explains what to do when the interviewer inevitably asks you to do it without using another buffer (reverse the whole string, then iterate through reversing the characters in each word).

A week or so later, I had a phone interview and was able to answer algorithmic questions speaking authoritatively about binary trees and heaps. That was enough to get me flown out to SF for in-person interviews, which at one point included a question word-for-word out of the book!

All that said… For a variety of reasons, I didn’t take that job. It just helped because I first spoke to Current during the weekend I was in town for the interviews, and got a chance to spend some face-to-face time at Current’s offices that day.

(In fact, the interviews with Current went by without a single algorithmic pointers-and-big-O question. And to me, that was a good sign, because as I say, I haven’t cared about that shit in 10 years—In my line of work, rather than optimizing lines of code, I’m more to get more bang by tweak a SQL query or throwing memcache at a problem.)

Which raises an interesting question: Is reading this book cheating? Is it the equivalent of just reading the answer key before an exam? In my opinion, no. For two reasons:

1. For the most part, it was just refreshing details I’d already learned during my CompSci course, but had filed away in the trashcan of my neurons, along with “Where’s the best deep-fried pizza in Edinburgh?”, as no-longer relevant to my life. This book probably won’t help too much if you don’t have the first clue about pointers or recursion to begin with.
2. If your ability to answer algorithmic questions is the only (or most important) thing the employer is rating you on when you interview you, then they’re fucking idiots and will get everything they deserve.

The book is just a handy tool for your belt when preparing for interviews, to get your mind in the right place to push past the algorithmic questions so you can present all the other amazing reasons why they must hire you right now. Similarly, I highly recommend reading Joel Spolsky’s Smart and Gets Things Done and Rands’s guide to how your resumé is being read for an idea on what the person on the other side of the phoneline or table is (or should be) thinking.

But without this book, I might not have passed that phone screen, and thus might not have been in SF when Current called, and might not have met with them, and might not have gotten excited by the opportunity, and might not have the job I have now.

And for that reason, I unreservedly recommend this book to every software engineer who might be on either side of the interviewing process soon.

Manmonthery

Capturing for posterity my scribblings from a mailing list discussion:

The “You can’t have 2 women deliver a baby in 9 months” metaphor always bugged me, because there’s no room for changing scope in that (You can’t opt to just birth the torso in 5 months, then add the head and limbs at a later date).

My preferred metaphor for explaining the mythical man month is that of getting a piano up a narrow stairwell. One person trying on their own would take ages, and there’s a high risk of failure. Two or three can probably get it done reasonably quickly. But if you try to get eighty people to do it, they’ll spend ages arguing about how to go about it, get in each others’ way, and in the end, two or three of the more productive ones will probably do most of the heavy lifting while the others stand around.

I usually illustrate this point with a shot of Laurel & Hardy from their 1932 classic The Music Box

(A quick Google shows that I nicked this metaphor from this blog comment.)