You Can't Google the Answer in a Google Interview

I spent over five hours interviewing at Google's Boulder office yesterday. My visit came about a month after I submitted my résumé, via a connection who referred me, to Google's famously challenging hiring process. Before I arrived at Google's office, I'd had my résumé selected from a large pool (which is probably full of bad programmers), had a non-technical interview with a recruiter about background and goals, and aced a technical phone interview. A large majority of candidates are eliminated at each step (possibly excluding the non-technical interview), so before my on-site interview, I already knew I was in the top few percent of people who apply to Google.

Preparation

In the week or two leading up to the interview, I alternated between a Zen-like state of confidence ("I've gotten this far, so I'm good; my whiteboard flow is tight") to fears of gross incompetence ("It's been over a third of my life since I've taken a calculus class and have forgotten how to add infinite sums! I can't remember any non-search graph theory algorithms!"). All my college notes and textbooks are in an inaccessible corner of a storage unit in Lakewood, but fortunately Wikipedia has plenty of reference material, usually at least as clear as CLRS. Looking through TopCoder problems, remembering ACM problems, poking around related websites, and finding blog posts, I felt like I could work through a solution to most. I worked through some dynamic programming problems to make sure I could recognize when the technique was appropriate and how to step through it. I dug into the implementation of some sorting algorithms, several types of trees and heaps, discovering the Cartesian tree, my new favorite hammer. I read a bunch of stuff about graph theory, realizing I need to read a good non-academic book on the subject, preferably one that aims to build spatial intuitions along with algorithmic reasoning. I made sure formulæ for combinations and permutations were in working memory and that design patterns, scheduling, and java.{lang,util,util.concurrent} were in at least L3 cache. I didn't follow Stevey's advice to do practice interviews, but I gave enough interviews at my previous job to be comfortable writing code without compiler or IDE.

Execution

So, how did my Google interview go? It started with a really easy Java question. Some people tend to get insulted at this step, but I know that an amazing number of people get to in-person technical interviews and somehow can't actually write code in their favorite language. I then implemented a method to see if all the numbers in one sorted list were in the other. Pretty simple stuff, but it's easy to go astray. My interviewer initially thought there was a problem in my code (probably a spot many people goof up), but I'd thought of the case and dealt with it. I noted that if I handled that section of the code a little different, I could get rid of some duplicate code I'd originally noted was ugly but functional.

Other coding problems included determining if a word could be spelled from a set of letters, making a deep copy of a graph with loops, implementing an LRU cache, finding an individual who satisfies an inverse relationship with every other individual, and writing a unit test for a simple function of a double. I had a "thinko" on the graph copying problem and didn't notice it when I traced through the code, but as soon as my interviewer pointed it out, I quickly reworked the function to handle the issue. I floundered around on the LRU cache because I've spent so much time thinking about collections and data as separate concepts that I forgot that any type of object can be a linked list node.

My weakest interview of the day was probably the last, with a focus on OO design and type hierarchies. The interviewer asked me to talk about some good OO design I did, so I started working through the object model for one of the big projects I worked on. I didn't realize he was mainly looking for object hierarchies rather than object relations, and after a little while I realized this wasn't a good example. I shifted to another project which I put a lot of design work into, but like most of our code at my last job, the inheritance hierarchy was pretty flat, with lots of abstract factories. The interviewer proposed a problem domain and I worked through a possible object model. Like I usually do at initial design stages, I was thinking in terms of types and data responsibilities rather than (Java) classes and interfaces, and it seemed like he didn't like that I was characterizing some things as fields. Hopefully I showed an ability to explore variations on modeling after a day of talking and thinking after a night of nervous bouts of sleep and wakefulness.

Google Boulder

I finished almost every interview section with time to ask questions of the interviewer, which made me feel like I wasn't failing too badly. I got some helpful opinions about the development environment (every line of code given a formal review before it enters the massive Google source repository), the company structure (the HR management tree is not identical to the technical decision tree and both have bottom-up flow), surprises about Google (a couple guys were impressed with how well Google worked as a large organization and how well they could collaborate with other offices). At lunch, the site manager for the Boulder office showed me around, talked about what goes on at the office (mostly apps and SketchUp, but with plenty of folks working on other stuff), and gave me an opportunity to ask a lot of questions. The Boulder office is tiny compared to the Googleplex (though it's a little bigger than the last office I worked in). They don't have high tech toilets, but there were magazines in the stall and reminders about build system usage posted above the urinals. The reception area has two big screens, one with a live sample of Google queries (quite a few were in Spanish and Portuguese) and one with a movie loop of Google Earth visiting some neat-looking locations. The most obvious thing you see if you peer in the building's doors is a rock climbing wall. The room also has (IIRC) ping pong, foosball, and pool tables, a Rock Band station, a multi-arcade machine, and some comfy chairs that probably did automatic massage. From the cafeteria (free snacks and catered lunch every day) you can look down into this play area while eating solo or sit with a bunch of friends at tables with Google-colored chairs. Most people work in "pods," open 4- or 8-person cubicle-like structures designed for easy collaboration. I like this kind of setup (at my last office, most of the software engineers removed at least one cube wall), especially with good noise-cancelling headphones, but it's not for everybody. The interview invite said "Leave your suit at home, Google is business casual." Since it was the Friday before Halloween, I was tempted to come dressed as a pirate ("Let's call this variable 'r'!"), but figured a brightly-colored winter hat would be a good compromise. I was glad to see at least half the office was in the spirit, including a couple (who had their baby with them) dressed as Skywalker/Leia and a guy whose costume involved not wearing a shirt (I disturbed some coworkers one halloween with my shirtless satyr costume in a standup meeting). One of my interviewers was dressed as a caveman, but he excused himself by saying he was filling in for someone who was sick that day.

Conclusions

An interview is an opportunity for the company to evaluate you and for you to evaluate the company. In the latter case, Google definitely succeeds. I like their approach to software development, I like their famously outside-the-box company structure, I like the office environment. (I let the recruiter know I'm interested in both Boulder and Mountain View; I haven't visited the fabled Googleplex.) In the former case, I think I have an outside chance. The site manager didn't know precise numbers when I asked what percentage of people get hired after an on-site interview. He said it was less than 50% and more than 1%, and said 15% sounded like it was in the ballpark. I know I didn't have a perfect performance, but I did a lot of things right and recovered fairly gracefully from errors. I definitely did better than 85% of people I've interviewed, but I suspect Google's earlier filters are a lot tighter. The guys who interviewed me yesterday will send their notes (including exact copies of the code I wrote) and a rating to a hiring committee. That group will talk things over and make a decision; the longer I don't hear back the better my chances (on the principle that it's easier to identify someone who really sucks from someone who's really good).

It's important to remember that not everyone who's qualified to work at Google get a job offer at Google, which means that if I don't get hired, I can't conclude that I'm "not good enough." The mistakes I made (which would not be present if I'd been asked other random questions) might lead to enough lower marks that don't pass the bar. They might also decide that given the desire to hire X people and Y people worth hiring, I'm not one of the best X in Y. Blog comments are full of people who think the following is sound logic: "(1) I am an AWESOME programmar! (2) There's no way I could get through Google's interview process! (3) Therefore, Google's interview process sucks! (4) Google's been successful up 'til now, but they're going to fail! (5, optional) They've got too many smart single young guys who work hard, that's the problem!" or "You didn't get hired by Google? That's because you're too good for Google! [And, one assumes, better than all these folks.]" Contrary to the haters, most of the people I interviewed with looked to be over 35 and (I'm pretty sure) some have kids. Interviewers might naturally tend to be older and more experienced, but I didn't sense a monocultureculture stereotypical hot shot 20-something computer nerds. (There was a pretty high male-to-female ratio, but that's a problem much larger than Google.) Also contrary to the haters, if I don't get hired it's probably because I messed up, not because Google messed up. And hey, if I don't make it, I can always try again in a year or two with more experience and insight under my belt.