Tuesday, May 03, 2011

How to Score a Google Onsite Interview

You might have heard that Google is looking to hire some 6,000 new employees this year. What that means is a lot of time spent by recruiters looking for candidates, talking with them, and then setting them up with one of us for a phone interview. If that goes well, we invite you onsite for a day’s worth of more intensive interviews, and if everything matches up we extend an offer, you take it, and you become a Noogler.

As it turns out, I get to do a lot of these phone screens, at least for aspiring front-end developers. And I’m frustrated by how bad it usually goes; that is, the interview itself was already a waste of time, but it’s compounded by the necessity to write a detailed account of the conversation to avoid frivolous discrimination lawsuits.
Of course, this is not a new problem; the reason why we don’t just bring everybody onsite immediately is that it’s better to waste one person’s time and discover a bad match than it is to waste 4-5 people’s time to make the same conclusion. That said, if you’re applying to an engineering position, here are some tips to save everyone some time and unnecessary frustration.

Clean up your resume
Be honest about what you know and what you don’t know in your resume. Yes, putting in a bunch of buzzwords will get you noticed by the recruiter, but quantify your experience with various technologies (e.g., “I’ve worked in: C++, Java; I’m familiar with: Python, Rails) so I know what’s fair game.
For whatever reason, front-end engineering candidates are particularly offensive; I’ll see someone put “expert in Javascript” on their resume, only to find that they barely know the syntax to jQuery and if I take the library away they will stutter and sulk in the corner. Be realistic about what you’ve done, and we’ll tailor our expectations accordingly; call yourself a “10″ in Python, and we’ll have Guido van Rossum interview you.

Know your computer science
It’s hardly a secret anymore that Google will ask its interviewees CS-type questions, from algorithms to runtime analysis to data structures. For whatever reason, we have people with 15 years experience, having forgotten what they learned in school, applying and then completely freezing up when we touch on these subjects. The truly outrageous ones will attempt to stall the interviewer while they frantically try to Google an answer.

If you’re not going to bother reviewing CS concepts or think that stuff is beneath you, you will probably not pass the phone screen and you’ll definitely not pass the onsite. I’m not even necessarily saying that this is a good metric – I’m a fan of giving small interview projects and pair programming for technical screening myself – but this is what Google does and you simply won’t get past the interview process.
Be comfortable with coding without a compiler/interpreter and in a shared document
Some programmers live by their REPL shell, and some hate having another programmer look over their shoulder while they code. Unfortunately, we use a shared Google doc to test your coding abilities, so you’d be better off being used to the feeling of coding in a shared environment.

Read more: AC