allenc allencheung

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.

On a related note, try to remember the syntax and API’s of your favorite languages and know the structure of the code, and make sure to list those on your resume. I’m personally lax at getting the exact syntactic structure correct in a non-computing environment, but I know some interviewers will ask for perfect code in a language the interviewee claims they’re familiar with, and subsequently point out compilation errors. At the same time, I do make note of programming quirks[1], and if you’re borderline those might make a difference.

Keep talking

For a lot of programmers, it’s unnatural to keep talking as they’re thinking about a problem or writing code. If you’re stuck on a problem, though, the easiest way to move forward is to tell the interviewer what you’re thinking, or even if you can’t think of anything at the moment. We want to move forward with the interview too; the more we get to ask you, the more data points we have.

And really, it’s in our best interest to help you get to a solution, even if you completely bomb the question. We want you to feel a sense of accomplishment and learn something, even if we don’t end up hiring you, so you’ll get a good feeling about the company and in the best case scenario tell your friends. I’d like to think that the slightly more positive interview feedback we’ve been getting on glassdoor.com means we’ve been doing a better job.

Ask us about our job, our work, and the company

At the end of the phone screen, we’re supposed to give you a few minutes to ask us any questions; take this opportunity to figure out whether Google sounds like a place you’d want to work. Not only is it important for you to figure out whether the environment and atmosphere jibes with your personality, it also tells us that you’re somewhat serious about the process, and you care about the culture as much as we do.

I remember back in the dark days, post-dotcom crash, when my company would send me to a career fair and I would be stuck listening to a guy with his 5-page CV, telling me that he didn’t care what he did as long as he got a job. Don’t be that guy.

Certainly, a lot of this advice isn’t specific to Google; our interview process is pretty standard for software companies, especially around these parts. That said, interviewing is totally unnatural for software engineers – I’ve always complained that most interviews tend to be artificial, administering a series of tests that bear no resemblance to the code you’d actually produce on the job. And I make no excuses for some of our interviewers who seem to have a chip on their shoulder and will put down candidates because they deem them unworthy of being a Googler, perhaps because they don’t have a Ph.D in CS or they don’t have a handful of github projects under their name.

If it’s any consolation, at least we don’t ask gotcha riddle questions anymore. Those were especially offensive.

Footnotes    (↑ returns to text)

  1. E.g., ++i vs. i++, length vs. length(), (“x” == x) vs. (x == “x”), etc.
By allen
allenc allencheung

Elsewhere