As those few of you who still have me on your friends' lists probably know, I work for Google.
As the rest of you may know, Google's a fantastic employer and many, many more people than we can hire want to work here. In fact, many more people with good resumes want in than would be practical to interview in person. Hence the phone screen, wherein a Google engineer calls you up and assesses whether you should be brought in for an interview.
I do about one phone screen/week, on average.
Sometimes my interviewees manage to seriously annoy me. As a public service, here's how to avoid doing that. Note that many interviewees who did not annoy me still didn't end up with in-person interviews, but that no one who did annoy me did. This is basically a guide for how to avoid totally bombing - if you want a guide for how to actually succeed at a Google interview, look elsewhere.
This applies only to people being interviewed for a technical position (i.e., Software Engineer or Site Reliability Engineer). Not knowing everything on this list does not make you a bad person, nor will I be pissed off at meeting you if you don't know everything on this list. It does mean, though, that you are not ready to phone screen at google for an SWE position.
- Know your terms of art; this applies to both CS terms and basic discrete math.
- Know the difference between the questions "What is implemented on top of X" and "How would you implement X"
- Know the difference between "X is a multiple of 3", "X is a power of 3", and "X is a third power"
- "packets" vs. "packages": know which one of these data travels over the network in
- If you claim to know java:
- Be able to code a simple "iterate over all elements of a collection" loop without looking anything up - the basics of the collections hierarchy isn't obscure trivia
- Know how to write a class that takes a particular type of object in its constructor
- know the difference between implements and extends
- If you claim to know C++:
- Know what cout << x << endl; does.
- Know what destructors are, and when they are executed.
- Be able to write a simple integer-variable-goes-from-1-to-n loop without sitting and thinking about it.
- Regardless of the language, know what all of the syntax characters do in any language you claim to know. (e.g., know what 5^2 is — it isn't 25. Neither is 5 << 2)
- Know what an IP address is.
- Know why people laugh at code that reads a 1000-line file by using 1000 distinct variables.
- Know something about Google:
- Our homepage is kind of famous. Asking as part of a question whether there are any images on http://www.google.com/? Not a good idea.
- Asking about the oppressive liberal bias in selecting Doodle images, also not a good idea.
- Don't be surprised and visibly dismayed that we aren't running everything off several large Oracle databases using Apache http servers talking to tomcat jsp engines.
- Be able to do some math:
- times tables (I can't believe I'm writing this)
- know that 211 is twice as large as 210
- With pencil and paper, be able to convert AB in hexadecimal into decimal
- Likewise, be able to convert 123 in decimal into hex