
What I learned interviewing with Google - wesbos
http://wesbos.com/interviewing-with-google/
======
varelse
Well, here's what I learned interviewing at google:

Be very good at off-the-cuff 80% solutions to topcoder problems on a
whiteboard, which I am. So much so, that when they told me to use whatever
sort algorithm I wanted to, I used bubblesort on purpose, to prove a point,
and got away with it. Later on, I reduced another interviewer's search problem
to a polynomial equation that had integer roots when a solution existed (at
which point he asked me what I'd do on an architecture that didn't have a
square root or a divide function and I replied "and what modern architecture
would that be?"). Which is to say their interview process is a computer
science puzzle game IMO. The skills displayed here have at best a loose
correlation with one's engineering skills, and that non-correlation shows up
like crazy in their codebases (but Steve Yegge already covered that far better
than I can).

So if you are a demo coder at heart, and you've been paying attention to
whatever technologies are the flavor of the month at google interviews by
reading blog entries like this (apparently javascript these days), you'll do
just fine.

In my case, it only took one round for me to get the offer which I
(unfortunately) accepted (but the tale of my 4 godawful months at google
thanks to naively letting myself get blind-allocated into the wrong team is a
different story).

Google is a great company, really it is. I know lots of relatively happy
people there, but focusing on the interview process is a mistake. The real
challenge is to get yourself hired onto a good team by resisting all the
pressure they exert to persuade you to jump into the blind pool, which is a
recipe for russian roulette. The solution, which in retrospect I smack myself
for not doing the due diligence to find out, is to insist on getting allocated
to and speaking with your future team as a condition of accepting an offer. Do
not compromise on this point.

~~~
ned_roberts
I'm in the process of negotiating for an engineering job with Google now and
it's been extremely difficult to get any information about what positions
they're actually hiring for. When I was there for the interview there was very
little time for me to ask any questions about what the teams actually do and
what I might be doing if I joined. This is very different from every other
interview I've had before where I'm talking to the team members I would be
working with.

Later, after talking with an engineering manager and getting agreement to be
assigned to one team, they tell me I'll be working for some other team as if
our conversation never happened. It's almost as if the attitude is that I
should be lucky to have been offered a job and I should be happy with whatever
I'm given.

~~~
nostrademons
Google hires into a general pool by design. It's because in companies where
individual managers have hiring authority, every manager has an incentive to
drop the hiring bar because it means he'll have more direct reports and more
resources to accomplish his own goals. Perfect recipe for empire building.

The time to negotiate teams is after you get an offer. If you have any sort of
negotiating leverage at all, you can probably exert some influence there.
Basically, multiple managers "bid" on Nooglers, and then the manager from the
highest-priority focus area gets him, modulo some input from the prospective
employee himself. When I was hired, I was told I'd be working on Google
Search, but the recruiter also said that if I didn't like that there were
multiple managers in GMail and Apps that also wanted me, and I could go there.

In general, your goal should be to avoid getting marginalized. Typically, the
highest-priority projects go to the best managers, who try to surround
themselves with the best engineers, so your experience will be noticeably
better on a high-priority project than a low one. The disgruntled Xooglers I
know typically left because they got assigned to somebody's pet infrastructure
project who somehow got headcount for a team of 3 or 4 but then has no idea
how to run a software development project successfully, and no support for
their ideas outside of their team. The happiest Googlers tend to be people in
core Search, Ads, infrastructure (eg. MapReduce/Bigtable teams), research, or
Chrome. These departments tend to feature large groups of loosely-knit,
largely self-organized teams, and very hands-off management.

It could actually be a good thing that you ended up getting reassigned; it
usually means that someone from a higher-priority area noticed your resume and
swooped in with a bid. But you should be able to talk to the new prospective
manager, or at least someone on his team. Every good manager I know will be
happy to talk to a prospective Noogler that they want on their team if it
means the difference between having them accept the offer or not.

BTW, I've noticed an interesting pattern where the culture of a focus area
depends a lot on the first employer of the founder/SVP for that focus area.
Search culture is Stanford culture. Chrome (which started from a bunch of ex-
Firefox people) has a very open-source culture. Android culture is Apple
culture with some Googliness thrown in (Android founder/SVP Andy Rubin worked
at Apple for his first job). Google+ culture bears an unfortunate resemblance
to Microsoft (Social SVP Vic Gundotra previously was in charge of .NET for
Microsoft). Apps culture is a hodgepodge from various other companies (most
apps were acquisitions). Infrastructure culture bears a strong resemblance to
Bell Labs culture (former infrastructure SVP Bill Coughran was a VP at Bell
Labs). I suppose the resemblance makes a lot of sense, and I wonder if other
large companies have a similar effect.

~~~
mysteryleo
What culture is ads?

~~~
nostrademons
I'm not entirely sure, I don't work there and don't know all that many people
that do. I think that core ads is like search, a heavily data-driven,
scientific, Stanford-based culture.

------
illumen
I make development software for companies like Google. Currently their biggest
demand is to be able to use their white board instead of the keyboard+IDE for
input. We call it an IDW, Integrated Development Whiteboard.

Also, they need tools to help them develop different sorting algorithms and
link lists. Plus they are having trouble with binary trees, but link lists and
bubble sorts are their number 1 priority!

Instead of more advanced performance modeling, they want to use this non-
sciency thing called Big O notation. Once they write a Big O notation on the
IDW(Integrated Development Whiteboard) they expect it to go that fast. If it
doesn't go that fast... they just chuck more servers at it (we supply their
servers too, so Big O makes us happy).

They also want us to provide them with flannel shirts and dr martins for
uniforms. They say that 90s clothes help them with their interviewing
techniques, because it helps them remember how interviews were done in the
day; when they were edgy.

~~~
alexgartrell
The forty yard dash provides one of the most important signals for football
recruiting. Essentially, it's a measurement of the time from when the athlete
takes his hands off of the start line to when he crosses the finish line. Most
commonly, it is run in cleats on grass with no pads, and certainly no players
trying to prevent you from reaching the goal line. In addition to that, the
best technique for running a forty, literally falling forward to build
momentum before lifting your hand off the ground, is actually illegal for
offensive players (and pretty pointless for defensive ones).

So why is this completely unrelated activity so important for measuring
football players? Because it takes ten seconds to measure, and a guy who can
run a 4.2 forty can almost always play pretty damn well.

Tech interviews today are a low cost way of getting a rough idea of ability to
code. Judging from Google's output, it's pretty damn effective for them.

~~~
rjsen
Except that the 40 really isn't a very good measure - if it were, the Oakland
Raiders would be winning the Superbowl every year instead of missing the
playoffs. Of the 15 fastest players in the last 12 years
(<http://en.wikipedia.org/wiki/40-yard_dash>), only 2 are stars, and most are
bench guys or out of the league. The 40 has its uses, but it needs to be taken
as one fairly small factor in evaluating a player, and even then it's only
really relevant for certain positions.

Similarly, coding algorithms on whiteboards doesn't tell you much other than
how good the candidate is at coding algorithms on whiteboards. Given that the
vast majority of their revenue comes from either search (which was built over
a decade ago) or companies they've acquired, and the numerous well-hyped
failures (Buzz, Wave, +, etc.), I don't think it's actually working all that
well for Google either.

~~~
alexgartrell
I'm not saying it's a perfect indicator, I'm saying it's a cheap and easy
indicator. Certainly there are outliers in every direction, but a running back
who runs a 5.0 forty just isn't going to be very good (unless he's like 400
pounds).

So is it more likely that Google is filled with idiots that can't see the err
of their ways, or that, across tens of thousands of individual hires, this is
the most cost effective and produces the best results (minimizing false
positives) on average.

College-admissions style interviewing just doesn't make sense for a company
like Google.

FWIW, there are a couple edge cases (like javascript/frontend engineers) which
my company (Facebook) has completely separate hiring tracks for. It works for
us, but I'm sure Google has its own reasons for not doing that.

~~~
rjsen
Actually, I'd say that whiteboard interviews are for Google are an arbitrary
way of selecting from already qualified candidates, just as 40 times might aid
a team in choosing between 2 otherwise similar players.

The players invited to the combine are the ones teams are considering drafting
anyway; all the 40 times do is move players up or down the list by generally
small amounts. The point isn't that 40 times are useless, it's that they
provide very little additional information about a player. Champ Bailey was
going to be a high draft pick no matter what he did at the combine, and
everyone already knew that Trindon Holliday was fast but probably too small to
succeed in the NFL.

Likewise, someone with a 3.9 from MIT or a bunch of good open source work
who's coming for an in-person interview is already qualified, and the
whiteboard doesn't tell you anything new. I'd guess Google sticks with them
for the same reasons teams tout 40 times - it's good marketing both internally
(making decisions seem less arbitrary) and externally (look how tough our
interviews are is a more socially acceptable way of saying look how smart we
are), and it allows people to deflect blame if a hire doesn't work out.
Judging by the number of posts about Google interviews I see here and
elsewhere, the marketing is certainly successful.

~~~
nostrademons
The vast majority of interviews do not result in a hire. (Some of my coworkers
have reported giving 20 in a row without a single offer.)

Also, I think your view of the interview pool is somewhat skewed. Most of the
candidates I see do not have 3.9s from MIT (BTW, I believe MIT has a 5-point
GPA, so it really would be 4.9), and a lot didn't go to Ivy-League
universities.

------
jumby
Typical Google waste-of-probably-a-decent-engineer. A javascript coder getting
asked sorting algorithm questions and Big-Oh notation. What a waste of time.
Google just doesn't get it.

I know all you fanboys out there will say "you need to know this stuff to be a
generalist software engineer" but c'mon, hire experts in sorting algorithms if
you need that for some obscure bigtable ultra-performant section of code and
leave it at that.

Need another example of wasting everyone's time: "She told me they primarily
hire strong C++ and Java developers, something which I have very little
experience with." Gee, Google, glad you still brought him in when he clearly
has no interest or background in that.

------
justin_vanw
I guess I don't understand the 'I failed to do this, let me give you advice
now' movement. From his own description the author is woefully under
qualified.

Interviewing is one of the purest Bayesian actions people do. We have to take
a bunch of limited and incomplete information about a person and try to
determine whether they are likely to succeed or not. Most interviewers would
love to find people that are smart, able to learn quickly and well, and
motivated, excited energetic. The best measure of these things isn't whether
the person seems smart, or energetic, everyone is trying to seem smart and
energetic and positive in an interview. The best measure is whether they were
smart and energetic in the past, and the best guage of that is how deeply they
learned in previous experiences. If they are a 'javascript programmer', not
knowing javascript syntax by heart is a strong indicator they just kludged
through without much deep interest in what they were doing.

Being unable to program on a whiteboard means you don't really know the
language you are using. Relying on an IDE to prompt you every time you make an
error is a huge crutch, and IDE's can only help you with obvious cases, there
are many times where you can get code past the IDE as syntatically correct but
logically wrong.

~~~
nessus42
_Being unable to program on a whiteboard means you don't really know the
language you are using._

This is nonsense. I have a degree from MIT. I've spent the last 15 years
programming in C++, Python, Scala, Lisp, Java, SQL, and JavaScript, etc. I've
worked on compilers, space telescopes, and brain surgery software, and I know
all of these languages fine. There's no way that I would be able to program on
a whiteboard without a lot of practice, however. Most likely, I wouldn't be
able to remember my own name if you made me stand at a whiteboard to program
in an interview situation. Fortunately when I interviewed at Google they let
me use pencil and paper.

Btw, I use Emacs much more than an IDE, and much of the knowledge I have for
syntax is built into my typing fingers.

~~~
atarian
Coding with pencil/paper is in the same league as coding on the whiteboard.
It's not nonsense and you know it too. You just deliberately missed the point
of his post just so you could brag about being from MIT and all the stuff you
worked on.

~~~
nessus42
It _is_ nonsense. I feel more strongly than you can apparently imagine about
this issue, and I would _never_ knowingly interview for a job that requires
coding on a whiteboard or on paper. I made a single exception for Google, and
I had to take tranquilizers not to throw up during the interview. I consider
this kind of interview to be borderline abuse. It serves no useful purpose
that can't be better achieved through different means other than to humiliate
those whose brains don't function well under this kind of pressure.

Btw, as far as I'm aware, Google didn't traditionally allow coding on paper--
they always required coding at a whiteboard. As I understand it, Google Boston
softened this requirement because it's rather counter to MIT culture. In four
years of undergrad schooling at MIT and quite a few additional classes as a
special grad student, no one ever made me work on a whiteboard, or do any kind
of work at all with someone staring over my shoulder.

~~~
spacemanaki
"I made a single exception for Google, and I had to take tranquilizers not to
throw up during the interview. I consider this kind of interview to be
borderline abuse. It serves no useful purpose that can't be better achieved
through different means other than to humiliate those whose brains don't
function well under this kind of pressure."

Is this really because of the whiteboard though? Interviewing is a stressful
thing to go through, and no process is going to be perfect for everyone. I
agree that in general it can be harsh on candidates who are not glib and
extrovertive, but this doesn't have much to do with the whiteboard.

~~~
nessus42
_Is this really because of the whiteboard though?_

Yes, I have no problem at all with a "traditional" job interview. Even ones
where I've been given a paper exam and then left alone for a while have been
okay. Though I also find that kind of interview to be rather distasteful, I've
never actually had any problem doing well on the exam. Doing well on written
exams (with solitude) is a skill that anyone who has graduated from a good
school probably has already been forced to acquire.

------
sitharus
I interviewed with Google at the end of last year. The only thing I took away
was that their recruitment people aren't very good at pre-screening and they
seemed to like wasting my time.

The first two interviews were OK, basic UNIX admin and software type
questions, I could answer most off the top of my head. The third was with
someone who certainly had a maths degree and wanted to make sure I knew it.

It all left a rather bad impression.

------
mundizzle
i hear stories like this a lot. serious question... why does Google ask
standard comp sci questions when interviewing for front-end developers?

in over 10 years of front-end development for non-trivial business
applications, i have yet to encounter a scenario where ignorance of bubble
sort prevented me from doing my job well.

i can tell you what i value when interviewing a front-end developer - in depth
knowledge of cross browser quirks and coding techniques to address said quirks
(sans jQuery). someone who can tell me what OOCSS is and why it's beneficial.
someone who values every pixel, http request, and div like it was their last
and uses them wisely.

i don't discount the value of standard comp sci knowledge, but i get rage face
if someone judges my skill as a front-end developer based on how well i answer
those types of questions

lastly, ever view source of any Google app? that tells me all i need to know
about their idea of a front-end development

~~~
derekdahmer
Similar to how graduating college shows you were able to work hard and learn
many different subjects effectively for four years, being able to solve a
google problem shows that you A) are smart enough to have understood and
retained it from when you were first taught it or B) were driven enough to sit
down and learn tough conceptual problems in a few weeks.

So, its less that you know that particular subject, and more what you being
able to pick it up is an indicator of.

~~~
mundizzle
Sure, I can understand that.

My point is that most of the very best front-end developers I've met don't
have CS degrees. So it seems unfair to penalize them for something they've
never been exposed too. There are other ways to assess someones conceptual
ability.

------
nohup
I got a call to interview with Google 10 months ago. Had two phone interviews
which went well, could not answer a Javascript prototype object model
question, but the interviewer was very kind go explain me where I was wrong.

After a few weeks went for an interview at their MV campus, awesome place. Of
the 4 interviews of 45 minutes each and one lunch session that I had, I would
say I did good in 2, fine in 1 and goofed up 1.

I did not get an offer, I had guessed that with how my interview went, but my
hopes were high :-). All in all I learned new things, met some excellent
people and had a great time.

I had read online about the white board process, so I was prepared for that. I
really feel for the interviewers that they had to sit for 45 minutes looking
at my bad handwriting ;-). The only thing that I could not understand was why
when I was not being interviewed for a traditional engineering role, I was
being questioned about Big O, algo design etc. The HR lady told me it would be
related to the area of my work (Web development, Javascript, Open source
contributions etc), but the interview at MV was not at all like that.

Having read other peoples experience with interviews at Google and the scale
of their APIs, I think at some point they are looking for people who can do
whatever is thrown at them and not just be bound to the technologies they
know. All the CS questions they asked me, I feel they were justified to ask
them, they wanted to find out if I will be able to work in other areas if need
be and not just be "a frontend developer". The interview was easy, I was just
not prepared to answer those questions.

Given a chance, I will do it all over again, but this time will go mentally
prepared for a CS 101 interview as well.

------
uberPhil
Sometimes I feel like it's a total crap-shoot with getting interviews at some
of these large companies. There were quite a few positions available in the DC
Metro area that I was probably more then qualified for or at least qualified
enough to get a phone interview. Needless to say, I was never contacted. It's
good to know that some people actually get to a phone interview :)

~~~
thinkdevcode
Do you really want to be subjected to coding on a whiteboard?

Edit: Instead of down-voting, why don't you explain to me why you would want
to code on a whiteboard when it's completely pointless. Might as well throw in
some of those pointless questions like why are manholes round?

~~~
jemfinch
I work at Google. We write (diagrams and code) on whiteboards on a regular
basis. We don't ask you to do it during an interview because we're sadists, we
ask you to do it during an interview because working here, you will be doing
it in the course of your ordinary work.

Beyond that, someone who's able to code on a whiteboard will _a fortiori_ be
able to code with a keyboard and editor, and will typically code better with a
keyboard and editor than someone who _relies_ on the keyboard and editor to be
able to code.

~~~
bad_user

          ... will typically code better with a keyboard and 
          editor than someone who relies on the keyboard 
          and editor to be able to code
    

The whiteboard sucks for problems for which you either don't know the
solution, or for which you know the solution intuitively, but can't reproduce
it line by line in successive order. In such cases people go back and forth,
adding new functionality or correcting the existing lines to fit a new
condition ... and this happens a lot for recursive algorithms. For instance I
cannot reproduce the in-place QuickSort line by line, but I can work it out by
evolving it from the basic idea, a process that takes a couple of minutes and
a lot of corrections.

So you're basically encouraging people that rote-learn solutions and that line
above is bullshit.

~~~
andrewflnr
Leave room between the lines so you can add stuff. Mark it up as you evolve
it. If you need to, you can rewrite the clean version on another part of the
board. Better yet is if you can figure it out in your head before you start
writing, becaus that will definitely make you a better coder.

~~~
jarek
> Leave room between the lines so you can add stuff.

Startup idea: a device on which you can write code which you can subsequently
edit by inserting, changing, moving around, and erasing lines

------
jmsduran
I had the opportunity to interview with Google. Overall it was a great
learning experience, and demonstrated to me the skills and aptitudes required
if I wanted to play with the "big boys".

Regarding their interview questions, you either know it or you don't. From my
personal experience, Google's rounds of questioning are intentionally designed
to weed out the people who fake it or try to cram up beforehand. For software
engineering, they are interested in applicants who naturally demonstrate keen
skill when it comes to CS fundamentals (algorithms, data structures, discrete
mathematics, etc.).

Throughout my phone interviews, Marissa Mayer's quote "A good student excels
in all subjects" kept running through my head. After interviewing with them, I
believe Google holds all their employees to a similar standard.

------
feralchimp
The most likely explanations for a company like Google using whiteboard
questions:

\- These interviews are easy to give for someone without good interviewing
skills, which is basically everyone.

\- These interviews are relatively easy to score.

\- Google acquires superstars through acquisition. If you need some competent
rank-and-file (i.e. a "pool") to support the superstars, whiteboarding is
maybe an okay way to weed out people who definitely won't rise to the
occasion.

It's a little insulting, but their pay scale probably balances that out.

------
garg
>The HR rep sent over an email with some guidelines and things to brush up on
which included comp sci 101 things such as sorting algos, hash tables, binary
trees and so on.

Does your NDA allow you to post these guidelines? Is so, please do.

------
nbclark
It's all about how you think under pressure. You have to know the basics, for
sure, but the interview is much more about seeing how you think and work
through problems. If you are getting asked to implement merge-sort or
something, probably not a great question. But whiteboard algorithm questions
let the interviewer see your thought process and how you think on your feet.

------
shtylman
Why would you sign an NDA for a job interview?

~~~
mapleoin
Some big companies make you sign an NDA the moment you enter the door. I
always assumed it's natural for ugly corporatey giants.

~~~
bstpierre
I've interviewed for _small_ companies that want an NDA at the front door too.

~~~
wavephorm
Do your profession a favor and DO NOT sign an NDA in this situation. It's just
terrible. Same goes for people that sign non-competes, and thought-police
agreements upon being hired.

Don't do it. It's optional, you have the right to refuse. By signing you are
putting a huge amount of liability on your shoulders for no reason. You're
giving that company the right to sue you for practically any reason they can
conjure up.

~~~
bstpierre
I don't really see the problem with a simple NDA.

Them: We're going to tell you secret stuff during the interview. Promise not
to blab? Me: Yeah, sure.

As far as non-competes and IP-assignment, from what I've seen these have
gotten much more reasonable over the past 15 years. If you write or invent it
on the job, it's a "work for hire" and the company owns it. What's wrong with
that?

If you don't want to sign, that's fine. But there are probably 400 to 1000
other people interested in that open position, and 99% of them are going to
sign the NDA.

Them: Please sign this NDA. You: No, I don't sign NDAs. Them (looking at the
next guy in line): NEXT!

------
findm
Your site is down for the count.

~~~
wesbos
hah sorry :\ Just refresh and it should load. Time for a new server.

~~~
Matt_Cutts
I'm glad that you had a pretty good experience overall. I know that lots of
folks at Google have worked to try to make interviewing less painful (like
limiting the max number of interviews you'll have to do). It's nice to get an
independent datapoint where the experience was pretty good, even if it didn't
work out this time.

~~~
wesbos
Thanks Matt, everyone I was in touch with at Google made me feel super
comfortable, you guys are doing it right :)

------
gaving
probably the most boring thing I've read all day

