

How to Score a Google Onsite Interview - allenc
http://allenc.com/2011/04/how-to-score-a-google-onsite-interview/

======
Locke1689
I've been thinking about interview questions recently. One interview technique
no one's used with me: "identify the problem." For example, let's say I asked
the following question:

 _What I need is a high-traffic scalable document store. The churn of
documents is going to be very high and the documents can be very large. I'm
going to need to regularly retrieve documents, but mostly only the documents
with the closest expire time. How would you go about solving this problem?_

Now, there are so many variables in this question that asking for a specific
solution is practically useless. Instead, it would focus on an interviewee's
ability to parse the computer science problem from the stated problem. I would
be looking for answers that include possibly building an index of the
documents stored in a distributed priority queue architecture. I'd ask them
where they expect pain points to be. Good answers would include things like
providing document synchronicity across a distributed architecture, providing
good failover in case of machine failure, and working out a sane and
minimalist communication API between machines.

Basically, I'm asking candidates _what_ they should Google if they were trying
to solve this problem. The answer given when many coding questions are asked
is "I'd Google it," but I've learned that recognizing what to Google is an
incredibly hard question. When you start dealing with problems harder than
"what was that function in the standard library called again?" it becomes even
more useful, because the question now isn't "what do I Google?", it's "What
papers do I need to read to understand succesful models of this problem?"

I'm just an interviewee still so I've never been able to give this method a
try, but I'd be interested to see if results are better or worse than current
methods.

~~~
namank
I had one like that, not with Google though.

Started off with "say your index.html is 500GB..." and a whole bunch of other
exaggerations.

I ended up designing a web server all the way down to the TCP/IP layer. Of
course, they stopped me and made me explain my design decisions along the way.

I accepted the offer. It was the best job I've had so far.

------
linuxhansl
Interviewing at Google is definitely an experience.

One guy came in and without introducing himself started to write numbers on
the whiteboard. He drew borders around some of them. Then he sat down,
introduced himself, and said that what he wrote on the whiteboard was machine
code. After explaining some of his nomenclature he asked me what I think that
code was doing.

Another guy asked me to solve a problem (don't want to say what specifically
it was, because they may still use that question)... Anyway, I could not for
the heck of me solve that problem. After 45 frustrating minutes of this he
started to write down the solution, then hesitated, then stopped, saying
something like "Hmm... It's not quite as easy as I thought".

In the end I ended up declining their offer. I spent some time on their
campus, and the vibe just did not feel right. Can't put my finger on it,
though.

~~~
millerc
I've been turned down by Google after the infamous day of interviews; passed
all of them with flying colours except the last one, given by an arrogant kid
whose every question seemed like entrapment. Recalling the warnings i got from
my HR recruiter in the first minute of the day, i have a feeling she knew what
i was in for.

I too had an extremely bad vibe about the campus. The ambiance on the whole
premises is the same as school : careless playful youth (even coming from the
senior engineers), toys everywhere, and the implicit deal that Google will
give you everything if you give it everything. I felt a perverse temptation to
give in to this, although i knew very well this attitude generates a
dependence relation in the employee.

After working in the austere world of avionics for over 10 years, i found it
absolutely shocking. But from their point of view, this is a winning
combination. It is just not conductive of hiring senior employees, of which
they probably have plenty supply anyway.

------
aaronbrethorst
I apparently passed a phone screen with them four years ago. Unfortunately, I
only found out that I passed the phone screen a couple weeks ago when a Google
recruiter called me up to inquire why I'd never interviewed on-site with them
after this failed recruiting situation[1].

Seemingly, having a friend who's in a senior exec position at Google seems to
be the only surefire way to ensure you get an onsite interview. At least then
your friend can hold Recruiting's feet to the fire.

[1] true story. I've elided some minor details which make the whole thing seem
even more farcical.

~~~
kbd
So they never got back to you and you never followed up? >.>

~~~
aaronbrethorst
They did, four years later, and no. I followed up multiple times. The
recruiter i talked to a couple weeks ago apologized for their lack of
followup. I still have no idea what happened on their end.

~~~
kbd
Ah that stinks, sorry :( It's awful having to wonder "what if". Plus, the on-
site interview is an experience in itself.

~~~
aaronbrethorst
Thanks, but it actually worked out for the best :)

------
nl
I've interviewed (onsite) at Google twice. First time I go invited back for
more (which I declined) but the second time I failed.

My second onsite was a pretty miserable experience to be honest - I just
wasn't doing well, and I knew it, but I couldn't get it together.

But one useful tip that did come out of it. The first interview (of 5) was via
video, and it took 30 minutes to get going. It was the first time the
interviewer had done one on her own, and she seemed more nervous than me. I
didn't do great, but did nothing terrible either.

Anyway, when it came time to finish, she asked me if I had any questions. I
was prepared, so asked her something, which she answered quickly - then asked
if I had anymore. I said no, and so she goes "well in that case.." and asked
me another interview question. And it was the one question I've had that I had
_no idea_ of how to approach.

Lesson: make sure you have _lots_ of questions, and keep them talking.

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

What, no more Fermi Problems anymore? No more reasoning about how many piano
tuners there are in Chicago? No more estimating how many hairs you have on
your head? Not necessary to calculate the total number of sheets of 8.5 x 11
inch paper used by all the students at the University of Maryland in one
semester? How many drops of water are there in Lake Erie? How many notes are
played on a given radio station in a given year, has become irrelevant? What a
loss ;-)

<http://en.wikipedia.org/wiki/Fermi_problem>

~~~
allenc
Hm, I think Fermi problems are not as much in style, but certain interviewers
still ask them from time to time.

I'm thinking more about just annoying puzzle problems with one right answer,
that if you don't have an "aha!" moment you'd probably never get (and
remember, this is in the context of a stressful interview). Stuff like the Two
Glass Balls problem:

[http://sites.google.com/site/mytechnicalcollection/puzzle/tw...](http://sites.google.com/site/mytechnicalcollection/puzzle/two-
glass-balls)

------
jchonphoenix
As it is in a lot of things, passing an tricky interview may not be the best
metric of coding ability, but it is indicative of problem solving ability.

It is the same reason top companies tend to recruit from top schools. The
chance that you pull a top notch programmer from a top school is higher than
the chance that you pull one from a mediocre school. In the same way, the
chance that the kid who passes your interview with flying colors is a good
programmer is better than that of the one that completely tanks.

------
Ugarte
I'd love to talk more about how we can improve on the typical fare of
programming and algorithm questions.

I've had to write my own sorting algorithm perhaps twice in the last some-odd
years. If you're writing sorting algorithms from scratch, you probably should
sit back and consult your standard libraries.

So if I ask a candidate some basic coding question and he can't write a for
loop, I know it's a no-hire. But past that basic bar, sifting apart the good
candidates from the great ones is actually very hard. Do we continue to ask
these questions because we can't do better?

(That's why I ask algorithm questions. I realize they suck, but I just don't
have any better ideas. I'm an engineer, not an HR flack.)

So what's a better way to test a programmer candidate?

~~~
Jach
If I'm ever in the position to interview, I'd ask the candidate to teach me
something of their choice. (Preferably something in the realm of technology
rather than how Magic: The Gathering works, but I'd accept either.) Teaching
me things I don't know is better since I'd rather have someone who has a
different knowledge base, though teaching me things I do know might help me
judge their ability to explain things. (e.g. making reference to an efficient
subway system (New York's) when explaining skip lists as done in the MIT
video: <http://www.youtube.com/watch?v=kBwUoWpeH_Q> )

A lot of my interaction between coders is explaining to each other what we've
done, I'd prefer someone who might be a worse coder than me but can explain
things well (and write good commit messages, etc.) than a guy who writes epic
code but can't explain it to me.

~~~
tincholio
A long time ago I TA'd at the CS department at my uni, and this was part of
the interview. You needed to choose one topic among several (beforehand, of
course), and give a lesson on it. It's a pretty good technique, indeed.

------
nicetryguy
recent college grad here

the conundrum is this. i spent my time learning the academics and theory of
programming, design, and business. jobs want experience.

i am an extremely fast learner, but cannot get a chance at a full time job
after being successful at a paid internship for over a year.

everyone is looking for experience, i feel like if you don't know Exactly what
you are doing day one, then you can't get your foot in the door.

yes, i have a website up, resume tuned, and a portfolio of what i have done.

thank god for unemployment checks... =/

~~~
ianl
Contribute to open source, and start your own projects. Show your passion for
what you do.

~~~
greengrime
Yeah, sure -- _in theory_. In practice, most people don't care.

I can't tell you the number of times I've had an interviewer come into the
room and clearly state that they haven't even read my resume yet (so excuse
them if they take a minute to look at it first), much less looked up my
projects or my website. This has happened everywhere, from tiny startups and
Google/Microsoft/Facebook to banks and contract positions. Even when I've
worked on projects related to the company (e.g., Twitter and Facebook apps
when I interviewed at them), the interviewers had no clue (and I mentioned
them quite prominently on my cover letter/resume/site). They don't look them
up afterwards, either (using Google Analytics, I can tell whether they've
visited).

There _have_ been a couple times when the interviewer has looked up and liked
my projects, and we've had fun discussing them, but this has been quite rare.

So unless you're directly using your projects to market yourself (i.e., you're
purposely using them to network, rather than just doing them for fun and
"passion"), I find this advice rather naive.

But maybe I'm just Doing It Wrong, and YMMV.

~~~
alnayyir
There's clearly something stymieing you here, and you're the common
denominator.

We're not psychic, if you aren't upfront with your lack of social skills, your
potential to be dunning-krugering yourself, or your unwillingness to write
code on your own time for the sake of it, we can't do much for you.

I had a rough start to my career (I have no degree and spent the latter half
of my senior year of HS trying to avoid getting slapped with a felony charge),
but I still managed to make it because when it came down to it, I enjoy
programming.

I enjoy programming so much that regardless of what happens in my career, I
will code.

I will code hungry, tired, or homeless.

I will code at night, in the morning, and in the afternoon.

Getting paid to code is a plus, but not the point.

This attitude showed, and I was eventually given a shot.

Where's your code? Why do you want to be in this industry?

Good luck sorting yourself out. The early years are usually rough.

I'm going to go get some night riding in.

2nd edit before I go: You shouldn't give a fuck if anybody, including an
interviewer, sees your code. One of the quirkiest but most interesting
programmers I've ever known is a 50-something year old that has worked as a
line cook his whole life (other than a brief stint in the military). No formal
education.

Rough around the edges, maybe 5 people in the whole world have seen his code,
and he's probably better at programming than you are...

...because he codes. His latest project? A pseudo-stack machine JIT runtime
thingamajobber. The man amazes and amuses me regularly.

~~~
Ugarte
"A pseudo-stack machine JIT runtime thingamajobber."

Ugh, really? I feel like 90% of the time if you find yourself writing a JIT
compiler, you're probably doing it wrong.

And "quirky" is not something I want to hear ascribed to a codebase.

~~~
alnayyir
You don't know this guy, I've known him for years.

Most recently, he's run into and fixed some bugs in _linenoise_ , which was
written by one of the most prolific programmers I'm aware of in recent
history.

Don't badmouth people you don't know.

Quirky was an adjective for him, not his code.

He's writing the it for fun, that's all. He has no needs.

~~~
Ugarte
Sorry if that sounded like badmouthing. Just a comment--I realize I don't have
the proper context.

------
latch
I don't know the difference between (“x” == x) vs. (x == “x”), and googling
isn't helpful (hah!). Anyone?

~~~
Luyt
"CONST == variable" is called a 'Yoda condition'. More information on this can
be found at [http://united-coders.com/christian-harms/what-are-yoda-
condi...](http://united-coders.com/christian-harms/what-are-yoda-conditions) ,
which describes its uses and advantages. I tried to use them a while, but not
anymore, because I find them unnatural; like reading backwards. In my opinion,
it's more logical to first introduce what is being compared instead of some
value which will be compared against. This is especially true if you revisit
the code after a few months.

~~~
pfedor
Furthermore, for many year now the compilers have been able to warn you if you
use = instead of ==.

------
mml
having "scored" an onsite in 2005, the phone screen was the easy part.

