I Has the Dumb (or: How I Embarrassed Myself in My Interview with Google)

double facepalm

When I do something, I like to do it big. When I blow a technical interview, I don’t do it with two programmers working out of a cafe; I do it with effing Google.

Landing an Interview with Google

My friend Enrico Bianco, who works at Google, heard that I was looking for other opportunities.

“There’s openings for developer advocate positions, and I think you’d be good at it,” he said in a Facebook chat. “You’re the only person who’s ever managed to make me reconsider my opinion that Microsoft is evil.”

I sent him my resume, and he submitted it a few days later. A mere 48 hours after that, I was contacted by someone at Google HR who asked “How soon can you be ready for a phone interview?”

I had that phone interview yesterday afternoon at 2:30, conducted by a Google developer advocate. He was quite personable, as a tech evangelist should be, and I was in my home office, on my own computers, and feeling quite comfortable. It should’ve gone off without a hitch, but instead, it went like this:

i has the dumb

The interview started off well. My resume, which is essentially a cut-and-paste from my LinkedIn profile,  is a pretty good one for someone seeking a developer evangelist / advocate / advisor position, and I’ve got my answers about what I’ve done and what I’ve learned down to the point where I can do them on autopilot.

The Programming Test

With the initial interview out of the way, it was time for a little programming test. For developer advocates, this is a less difficult test than for those who do actual production coding, and in an attempt to ramp up my skills and build a portfolio, I’ve been doing at least an hour of iOS coding after work on most days. The purpose of this test was to see if I could code at all, and he would’ve been well within his rights to hit me with FizzBuzz.

“Time for the coding test. What language would you like to do it in?”

“How about Ruby?” I answered. I picked it and opened irb in a terminal window so that I could double-check my work.

“My Ruby’s a little rusty,” he said, “I’ve been doing more Python these days.”

Score one for my Batman-like strategic thinking:

batman wins

I’ve heard that the languages in general use at Google are C++, Python, Java, and JavaScript; going with Ruby meant that he wouldn’t go all “language lawyer” on me. It became clear to me that I’d made the right choice when he tried to use __init__ as the name of a class constructor (that’s a Pythonism).

He typed a class like the one below into a Google doc. This is a cleaned-up, working version of what was typed:

# Cleaned-up working version of the class
# that he typed into Google Docs

class MiniGoogle

  attr_accessor :index

  def initialize
    @index = {}

  def add_to_index(url, body)
    @index[url] = body


“Let’s say I’m making a cheap clone of Google,” he said. “And I’m using this class to store an index of pages by their URLs.” It was a rather Googly example, and it made sense: some client code crawls the web and records the URLs and content of the pages it crawls into an instance of MiniGoogle with add_to_index. He then typed the following:

def search(term)

“Finish this search method,” he said. “It should return only those pages containing the search term.” “Seems straight-forward enough,” I said, and got to work. I couldn’t remember the name of the Ruby string method for determining if a string was a substring of another string. Luckily, I’d already had open, but the brain just wasn’t working. I searched through the documentation for the String class, probably scrolling past index at least two or three times before finally spotting it, thinking out loud for the benefit of my interviewer. In the end, I typed up something like this into the Google doc:

# My lame attempt

def search(term)
  results = []
  @index.each do |item|
    if item.value.index(term)
      results << [url, body]

The code above won’t work at all. I’d completely forgotten how you run a hash through a block in Ruby, and I’d also forgotten to return the result array. If I’d looped through the dictionary properly, the code still wouldn’t work, as it would just return the last value it referenced, namely @index — the entire collection of page URLs and their contents. Duh. Here’s code that works…

# This works, but it's wrong for other reasons

def search(term)
  results = []
  @index.each do |url, body|
    if body.index(term)
      results >> [url, body]

Once I was done typing, the interviewer gave my code a quick glance and said “You know, I was kind of hoping you’d do it another way, say using select.

That’s when I got this feeling:

Not only is using select a more elegant way to solve the problem, but it’s exactly the approach you want to take in an interview with Google. When your bread and butter is crunching through large amounts of data with MapReduce, it only makes sense that you tend to take a more functional approach and think in terms of single-operation mapping, filtering, folding, and sorting. Once upon a time, my job was to be able to get inside programmers’ heads and know how they approached problems and why, and I completely forgot to do that.

I could blame my “let’s iterate through the hash and perform a test on each element as we go” approach on all the coding I’ve been doing lately has been in Objective-C (which doesn’t have all of Ruby’s functional niceties), but I have no excuse for blowing this. I’ve actually written a whole series of articles on the power of Ruby’s Enumerable module, including the select method (and what I think was a pretty clever explanation of fold).

I thrashed about on the Google doc, finally writing something like this in half-pseudocode:

# Wrong 

def search(term){|item| item.value.index(term)}

As Murphy’s Law would have it, after the call, I whipped this up in seconds:

# Right, but too late to be useful for anything
# other than a code example in the blog entry
# documenting my FAIL

def search(term){|url, body| body.index(term)}

After that disastrous coding-in-a-Google-doc exercise, it was back to more Q & A, with me asking my interviewer questions, such as what a “typical” day for him was like (and yes, developer evangelism is so all over the map that there are few “typical” days).

I also asked him a number of questions about what Googly life is like; after all, I sure as hell wasn’t going to experience it after that interview.

Lessons Learned

I’ve hosted a number of “FailCamp” events, which are big confessionals where you stand in front of an audience and tell them your best story about FAIL, and then the lessons that you took from that experience.

I can’t blame it on nervousness coding in front of others, because I used to do that all the time. Anyone who’s seen my “Biebersmash” Windows Phone game development tutorial presentation knows that I start with an empty Visual Studio file and live-code it in front of an audience.

While my work for the past year has involved little or no coding, I can’t say that it’s been a while since I’ve written a program. In fact, I’ve been doing a little bit every day, working on my iOS programming and even managing to squeeze in a little Android. I’ve been writing iOS programming tutorial articles. I’m not what you’d call a seasoned pro yet, but I can make apps that actually work.

I am terribly out of Ruby practice. In the interview, I found myself looking up the simplest of things in the Ruby documentation. Dead air is deadly during an interview, which meant splitting my attention between looking up information and keeping the conversation going with the interviewer, which just slowed me down. If I could do it again, I’d love to prepare by noodling with Ruby, just to harness the power of habit and make sure I had my “sea legs” for the interview.

I’m going to take the philosophical approach to this. First, it’s gratifying that I could land the interview and that they wanted to talk to me rather quickly. There’s also some wisdom offered to me by computer science professor and C# book author Rob Miles: “What doesn’t kill you makes a great blog entry.”

get up and deal with it

Got a story of interview FAIL? Feel free to share it in the comments.

Be sure to read the follow-up article!

30 replies on “I Has the Dumb (or: How I Embarrassed Myself in My Interview with Google)”

I wouldn’t worry about it. Larry Page & Sergey Brin did not even know HTML when they launched Google. And that was back before HTML was complicated with floated divs and CSS selectors. We’re talking “b” for bold and “i” for italics. I bet the original Google search engine was just a few Perl scripts and some “flat” text files with no database.

A good interviewer would have asked you if there was another way to do it before writing you off, if that is what actually sunk you.

pj brunet: even by ’98 the web was too large to index with a single machine and you certainly couldn’t do any sort of reasonable search with a flat file. The paper describing the original Google architecture is easily Googleable.

Thank you so much for writing this blog entry.

The same happened to me a couple of weeks ago. I was utterly intimidated and said the most outrageously dumb things during my Google interview. Knowing someone else experienced this makes me feel less silly.

Hope you are more relaxed in your next interview. ;)

Good luck with your search for new opportunities!

I did almost this exact thing in my tech screen for Google a year ago.

I went into way more nervous than I should have been, and the guy interviewing me sounded like he didn’t want to interviewing anyone that day.

When he asked his first question, I asked a follow-up, and he made fun of me because he thought it was stupid, and I was screwed for the rest of the interview. I was afraid to speak more than necessary or ask more questions.

I blanked on questions I would have easily known the answers to, and the guy said I wasn’t allowed too open a command-line or browser tab to try anything or look up answers. One of the questions was about command-line switches to tar, and the guy said I couldn’t use –help. I had to do guesswork in the Google Doc we had open.

I was virtually panic-attack-level nervous, and he was impatient. It was very embarrassing. It took me a few weeks to get over it. I hope anyone else who does this can benefit from your blog. I wish I had had it right after my interview.

Yeah, I failed their quick pre-interview filter questions on “what’s the system call to open a tcp connection”. Derp. I also failed “how do you determine what runlevel your unix system is booted into on most unices”. Derp^2. (Ive only been messing with unix since 1988, so gimme a break.)

I realised my fragile ego wouldnt handle a real interview they invited me to (also: my wife wouldnt be moving to New York or the Bay Area any time soon), so I just wimped out on the whole thing. What Might Have Been (and would have certainly changed my morning pyjama’d (were I to ever wear jammies) 8-metre commute from bed-to-home-office at approximately 10-11am every day… ) [“Real job? What!? Lol.”]

Good luck next time :)

Fizbuzz karma’s a bitch. ;)

Came here from the follow-up so it’s not all bad.

Good luck.

@Inhaler old comment but in response to “too large to index with a single machine and you certainly couldn’t do any sort of reasonable search with a flat file.”

I never said anything about a single machine. I think you missed my point. BTW, searching flat files is easy with grep ;-)

lost today… the worst part is i realized the answer like 5 mins after the interview.. i got the lower bound atleast (yea…).. not easy to go through or deal with afterwards.. of everything I studied prior, a grand total of 0.0% was useful (or even relevant).. they really want fast minds I think, which I guess I’m not..

Same thing happened to me at facebook interview,The Interviewer provided me a question which was easy for normal candidates,But i took in to other way i made it complex,I thought too much but the interviewer guided me to the correct but at that time i was nervous because attending the interview of a large company,my head turned in to blank,I couldnt proceed with anything,I am making mistakes over mistake and i am totally numb.The interview ended by one hour,Sadly i knew,my chance is over.A week later i got mail from FB,They are not proceeding the further interview with me.

I failed at the technical interview, my dream job at a large company too and I have been coding for years daily.

I was nervous and was one upped on one question by another guy based on the feedback given. You need to be super relaxed when you have the interview because nerves will ruin your chance.

As cathartic as this is, I think it would be helpful if we could also talk about how to stay sharp when you don’t have to code for up to a year. I tried exploring functional programming through scheme (great mind trip) as a way to stay involved programming wise. However I ended up totally phoning in a simple javascript test a few weeks ago.


Thanks for writing this blog article. I have also failed with google twice before and recently made it to the onsite (it’s scheduled for January).

The one mistake you seem to have made is that you actively tried to search/validate your thoughts/doubts on irb / internet. Maybe your interviewer failed to tell you, but it’s often a rule that you should not (unless explicitly told otherwise) consult anything and stick to the shared document. It’s quite easy to detect when someone is trying to search for answers elsewhere. As someone who interviewed 50+ systems engineers and developers at Amazon, I have failed a good number of them based on hearing sudden keyboard strokes during his silence and sometimes perfect recitations from wikipedia. It’s about what you know and how you can work around your difficulties / come up with solutions on the spot.

Not saying it’s completely fair, but it’s only the recruiter interview that is a filter based only on just linux & sysadmin 101 and you only need a handful out of 10-15 questions to be right.

18+ years of professional experience here in a variety of very senior dev, lead, and architect roles, and I gotta tell ya, I still hate (and perform miserably at) tech interviews.

I’ve found a few things over the years have helped:

(a) Don’t cram before an interview as you would with other tests. I’ve done this before many times, and it always seems like you’re working so hard to cram as much “rusty” knowledge back into your head as possible that you’re almost certain to forget other — often more relevant — things by doing so. Now, I never read anything technical before an interview other than code I’m currently writing.

(b) This may irk some, but I’ve found interviewing for positions you don’t really want (or need) is helpful. Other than simply keeping you fresh (as I’m guessing most of us aren’t interviewing that often), I’ve found that my attitude is notably different (in a better way) when I’m interviewing for a position I don’t want.

Once, an interviewer for a job I wanted asked me the difference between an override and an overload, and I had a brain-fart and made up some half-baked answer to attempt to save face. It didn’t work.

On the other hand, at one interview for a job I wasn’t serious about, the guy asked me about the difference between .call and .apply, and I just flat out said something like, “I always use .call, so I don’t remember; I’d have to look it up.” The guy’s response was, “Fair enough.”

I generally find myself more relaxed in the interviews I’m not serious about, and I try to bring that same zen to those that I am serious about.

Easier said than done, I know…

My last job(a small embedded company), I completely blew the interview. I got asked softballs like “what is inheritance?” and of course I blanked on almost all of it. Somehow I got the job. well not somehow.. they were desperate.

I just graduated and took an off-site test for the only company nearby that I want to work for. I have literally written half of the program they asked me for before just for fun, 2 or 3 years before I graduated. It’s the exact stuff I love playing around with. And still I blew it… barely got it 1/3rd done. Trying to figure out if it would hurt or improve my chances to finish it and submit it.

I also blew it with Google. I was interviewing for a sysadmin position, leaning heavily on 15+ years experience with various unix variants. The interviewer asked me “How do you run a program as root?” I thought that he was talking about services, so I said “You don’t”, then explained why it was a bad idea to run things as root. I thought I’d nailed it, being as I’d demonstrated knowledge of services, security, and best practices. About an hour later I realized that he was asking about using ‘sudo’. I didn’t get the job.

Great post. Appreciate the honesty. I had an interview for a job just the other day and I totally screwed up a C# test. It was horrible. Full of spaghetti code nobody would ever write unless they were trying to totally confuse some poor bastard looking for a job. Of course, I could have solved it all had I been at my desk with Visual Studio and stack overflow etc.
If the company had still been willing to take me on I’d not have wanted to be among them anyway, the bastards..

Comments are closed.