How to not piss off your Google interviewer

[dtm]

Yeah, yeah, haven't posted in ages, etc.

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 2¹¹ is twice as large as 2¹⁰
  • With pencil and paper, be able to convert AB in hexadecimal into decimal
  • Likewise, be able to convert 123 in decimal into hex

Comments

[astrogeek01.livejournal.com]

...

Um.

I know *I'm* not qualified to join you guys, and I know most of that stuff...

Though, I'm curious: how does one go about answering coding questions over the phone? I'd have to sit and write it down (I don't think I could just -say- it, I don't think my brain works that way). Though I guess I could write it down and then read it to you?

I've never bothered to learn the hex stuff, though.

[juan-gandhi.livejournal.com]

There was a time when we practiced this: share a document on docs.google.com, where the interviewee could write some code. But I did not like it actually; not seeing and not knowing the person may give a very biased perception. It's easier not to go deep into coding while interviewing over the phone. There are questions that easily tell the difference between a practicing programmer and a talker.

[dtm]

I'd have to sit and write it down (I don't think I could just -say- it, I don't think my brain works that way). Though I guess I could write it down and then read it to you?

That's usually how it works, though I have also used the "shared google doc" method.

This means that coding questions for phone screens are chosen so that they have a short relatively obvious solution.

[astrogeek01.livejournal.com]

Ah, I see.

I do find it interesting the weird ways my brain works. Like, I think typing bypasses parts of my brain that hand-writing things doesn't. I have to think far more about spelling, for example, when I write things vs when I type.

[juan-gandhi.livejournal.com]

"Know how to write a class that takes a particular type of object in its constructor" - what can this possibly mean? Is the following the right example of what you are asking:

class A {A(Integer b){}}

[juan-gandhi.livejournal.com]

Could have been a Scala programmer you were interviewing.

[dtm]

Without going into details, I am certain this was not the case.

Even if it were, the candidate:

1. Claimed to know Java, and
2. was explicitly told that this was a Java question
3. Used java-specific syntax such as implements in the remainder of the answer to the question.

[janne.livejournal.com]

Asking about the oppressive liberal bias in selecting Doodle images

I was wondering the other day if there was much screaming over Darwin Day :)

[dtm]

I actually haven't heard anything in interviews over that particular image yet, but I'm sure I will.

[astrogeek01.livejournal.com]

Aww, I liked it!

Oh wait, I'm one of the liberal biased people, aren't I?

[jmartin2.livejournal.com]

Totally irrelevant to the conversation, but LOVE LOVE LOVE the icon!