So I’ve now completed the interview process twice with Google (once in 2007 and once in 2010), and while I’m not sure advice from someone not hired after two run-throughs is all that useful, I figured that the more information out there for those undergoing pre-Google-Interview stress, the better, so here’s how it went.
In both cases, I was contacted out of the blue by a Google recruiter. The first time I had been considering looking for a new role and pursued it immediately; the second time I hadn’t been and put off the recruitment process for several months, during which the same recruiter contacted me again twice to follow up. If nothing else, that’s a nice ego boost, but a more cynical mind might be considering the shotgun approach to a narrow recruiting filter and commissions
First, a quick data point, I was applying for an SRE(SA) position on both occasions – Site Reliability Engineer (System Administration), because in most of my roles to date, I’ve been doing both sysadmin and development work and I’ve never seemed to drift towards one pigeonhole or another. SRE(SA) seemed optimal – interesting sysadmin work on large-scale systems and quite a bit of tool-writing to boot. This was decided on between myself and the recruiter, based on the self-assessment form you are given to fill out. I would love to know how they get around illusory superiority and the Dunning-Kruger effect with those forms, especially given the wierd bias they’d have in the dataset from having so many of the best in their fields working there.
Both times, the process proceeded in the same way: the recruiter themselves carried out the initial phone screening, an idiot test of basic knowledge. The questions at this level are more broad than deep, and you really are talking about easy things like basic unix commands and the like.
The second phone screen was more demanding technically, and was of the same mould as the famous “why is the sky blue?” physics exam question, with an initial simple answer and then drilling more and more into that answer. In my case, both were focussed on the level where user-level unix meets the underlying systems, the sort of thing you’d encounter in writing any kind of sysadmin tool. If I had to give hints here, it would be to know the underlying systems, their APIs, and the unix philosophy for writing tools to work with them.
I’m not sure hints are of much use for Google interviews though – there are many sites saying they have questions used in Google interviews, but I’ve not yet encountered one of those examples after fourteen interviews. Knowing how to tackle Fermi questions (back-of-the-envelope estimates using what seem to be reasonable assumptions, such as “how many golf balls fit in a bus”) is probably a good idea, though I’ve only encountered them in passing; and big O notation has never come up. However, I think that SRE(SA) questions probably lean far more heavily towards the practical workaday stuff than towards application-level design fundamentals. Presumably there’s a different balance for developers. Certainly, practicing fault diagnosis in networked systems would be a good idea, and having your internal process for diagnosing faults well defined in your own head would be an even better one – that’s what the interviews are looking for and if you don’t have it clear for yourself, they can’t spot that.
I would also suggest practicing writing code longhand, in one of the Google languages (C++, Python and shell script seemed to be the most popular). And I don’t mean coding on a machine, I mean writing the code longhand into a notebook and then typing it verbatim into a machine to test it. For a nice side effect, this’ll improve your penmanship and that may prove useful because you will be working a lot with a whiteboard. Incidentally, one of the better tips I’ve come across was to bring your own whiteboard markers (thin ones); it effectively gives you more room to work with, and whiteboards are never big enough, no matter how big they are…
On both occasions, I then went on to do the on-site interviews. In my case, this was logistically easy as I was very close to the Dublin office, which is currently the second-largest Google office worldwide, so I didn’t have to fly to California or anything so onerous, but all five on-site interviews were held on one day, back-to-back, which is a bit exhausting. And on both occasions, the experience was about the same; initially you notice very Californian decor, with even the temp receptionist surrounded by a dozen or so lava lamps in alternating colours, with everything nice and brightly lit, and with swiss balls everywhere acting as seats and so forth. It does sound very Dr.Seuss, and it is in a way, but it’s a lot nicer than that sounds to be honest (if a bit… young), and there’s definitely an element of creating a culture through a particular physical appearance. The entire office complex is self-contained for the most part, with its own on-site canteen (which, by the way, is quite impressive – any canteen that can cook cous-cous properly for a thousand or so servings, while serving up at least four other lunch menus, is showing off very competent catering skills indeed, even if noone’s noticing most of the time), gyms and so on. In fact, walking around the streets you’d never know how many people are working in the offices from a casual glance.
Again, on both occasions, the procedure was the same – I was met in reception after checking in by the recruiter, who’d booked an interview room and who walks you around the office a bit on the way there. Take a look around at this point; it’s an interesting office setup. Once there, the recruiter introduces the first interviewer and leaves you to the interview process and retrieves you at the end of the day to walk you out (after which point, the interviewers write up their reports and the hiring committee makes a decision. Start to finish, it’s been three to four weeks each time from initial contact to final decision).
There were five interviews back-to-back each time, and the technical areas covered for me were those you’d expect for such a role: Design and Coding approaches; Unix/Linux sysadmin stuff; Networking; Scripting; Troubleshooting and problem-solving; Disk and storage systems. One google expert in each area, with the brief to start light and then push and push until you’re out of your comfort zone and well into your sweaty, stressed, exploding-head zone. If nothing else, you do wind up learning things from Google interviews, which is reason enough to undergo them to be honest. I didn’t know about isatty() until this round of interviews, for example. I don’t know of any other interview process that could be counted as a continuing professional development activity
I’ve read accounts of Google interviewers being uninterested in the interviews they’re carrying out and being borderline rude in some cases; I have to say, I never encountered anything like that in any of the fourteen interviews I did over the two occasions, and never encountered anyone doing an interview who was less than professional about it; and most, if not all, were quite happy people during the interviews. Honestly, I never picked up on any personal or professional issues towards me, there was nothing but buy-in to their way of doing things. Which was quite impressive – I’ve interviewed with companies before where the interview felt more like a test of how much abuse you could tolerate, or where the company was simply wasting my time and theirs (for example, calling me in for an onsite interview that ate half a day, only to announce that they couldn’t pay me more than 60% of the expected salary).
There’s not much feedback in the interviews though. That’s about the only real criticism I have of them. I can understand the hyping of the interviews – as much as you try to null it out, it does create mental stress and some think that gives greater insights into your real abilities (although frankly, it’s not the same kind of stress as you get during your daily work, so I don’t think it’s as useful as you’d imagine). I can understand the mythologising of the Google workplace (and given the professional and personal advantages that workplace offers, I can accept it as the cost of doing business).
Actually, to digress for a moment on the workplace, I should point out that one of my main concerns while interviewing was how Google and professionals with families get along. Famously, Google is a young work environment, and while an eighty-hour work week, all-nighters and completely obsessive behaviour around your job is something you can manage to do in your early twenties, I don’t think you should do it – I think it’s one of our industry’s worst cases of macho-driven work practices, and a main reason for the high instance of IT project failures. Beside that opinion however, there’s the very real point that by the time you hit your thirties, you have to worry about wives, children, and other family things outside of work; and often you are faced with a choice between being a good employee and being a good person (and yes, I count letting obsession with work take over time that belongs to your family as a character failing; and no, that’s not the same thing as having to work long hours, that’s a different thing entirely).
Google, however, seems to have taken this on-board, and everyone I spoke to about it had similar experiences – the mean age of the work force in Google is increasing, and more and more now have young families and work practices and facilities are changing to match the new demands. Childcare is the new free food, being family-friendly is now part of doing no evil.
Feedback, however, is still a verboten topic. Interviewers don’t (and one told me they’re not allowed to) give feedback; nor are you given any if the hiring committee decides not to go with you as a candidate (which is what happened in both cases for me). That is rather fustrating – there’s no way to tell if you flunked a particular area, or if it was just that it wasn’t thought that you’d fit in with the Google environment. So you can wind up going through a process taking a few weeks, bringing a lot of stress, go through seven (or more) interviews, and not learn at the end if the problem was your technical proficiency or your popularity. Which is… suboptimal, at least from the interviewee’s point of view. From the interviewing company’s point of view, I suppose it could be said that every minute spent on a candidate after a decision to not hire them is a wasted minute; but the fact that you could be coming back to that person in a year or three does somewhat argue against that view.
In short, it’s pretty tough, you will have to study hard for it (well, that’s to be expected), you may find your brain stalls because of the stress on things you fully grok day-to-day (that happened to me several times), and at the end of it all, you might be turned down purely on social reasons without ever being told it was because of workplace fit instead of technical competence. It’s still worth doing though, if only for the experience. Good luck!