
My Job Interview at Google (2008) - kureikain
https://catonmat.net/my-job-interview-at-google
======
googlempl2020
I work at Google as an SRE, joined a few years ago. I am approaching 40,
worked in a bunch of other companies before. My degree is is in the
humanities, from a third world university you never heard of. I don't have any
open source contributions. I speak lousy accented English (but I am a man and
"white" if we are counting privileges.)

I got contacted by a recruiter. I had a couple of phone interviews which felt
like sanity checking that I knew what I claimed to know. I was asked to grade
myself in a bunch of areas. I chose makes around 5-6 for the stuff I think I
know well, and zero or one for the rest. I was given some recommended reading
list that I ignored. I did browse Skiena's book on algorithms to get in the
zone. I didn't study it or implement anything. I am very stressed during
interviews and would forget anything that isn't in long-term memory already so
there was no point. (know yourself...)

I went to the onsite interview. Year, it's ~5 hours of being interviewed by
people who have done dozens of interviews before. Everybody was unfailingly
nice. I was panicing, not because "omg Google" but "omg humans I don't know
for years already". Some algorithms, some Python, more troubleshooting and
Unix. I had to estimate some numbers, so I announced I would use my cell phone
calculator to not get anything wrong. I multiplied even low numbers by two on
the calculator. Most interviewers are poker-faced about whether they liked the
interview or not (now that I am an interviewer I understand - they probably
try to put some distance between the interview and their rating, as they
should). I could see that one was happy. I could see that one was not.

I was hired. Large team, three sites. I did a reasonable amount of C++ (not a
language I ever claimed to know) fixing bugs and performance issues. Most of
my work has to do with low-level synchronization in x86 - I picked a small
"specialty" first and applied it to a number of problems. I like it. I feel
that I actually write more code than my peers in the product teams, as they do
too much design-docing, design-reviewing, meeting, etc. (they are SWEs, I am a
SE). The design doc culture at Google is excessive and silly. I am exposed to
that too.

I earn slightly more than my similarly-leveled peers on the SWE side /before/
accounting for oncall. Oncall rarely pages on weekends. I feel very able to
fix any problem while oncall, or to escalate if not in my area. It doesn't
stress me. I mostly consider it free money.

My peer SREs actually know far more about all the nice Google architectural
stuff than our peers in SWE-land, who are mostly implementing features on top
of huge abstraction layers and typically are only exposed to one particular
facet of the infrastructure. Google's infrastructure is impressive and
something of a marvel. It doesn't mean it's perfect. SRE is the better point
of view to observe it.

Google employees _are_ better than in any other large company (a few boutique
shops are better on average, of course, at a smaller scale). Some of them like
to pretend that they are better than they are to the outside world.
Internally, nobody goes far being arrogant, and showing vulnerability or gaps
in knowledge is not a problem. There is also someone smarter and nicer than
you anyway.

I interview people. The immense majority of people I interview are really
good. It's not possible to get to the point of onsite interviews unless you
are good, you just know the person you are talking to is a potential peer.
Interviewers are happy when their candidates do well. The committee ends up
rejecting most, though, out of hyper-conservatism. I have no idea how I was
hired. I suspect there is a large amount of randomness between "invited for an
onsite" and "hired".

~~~
hckr_news
Interesting comment. Thanks for the write up.

> The design doc culture at Google is excessive and silly

I have a friend who started there last year and said the same thing.

> My peer SREs actually know far more about all the nice Google architectural
> stuff than our peers in SWE-land, who are mostly implementing features on
> top of huge abstraction layers and typically are only exposed to one
> particular facet of the infrastructure. Google's infrastructure is
> impressive and something of a marvel. It doesn't mean it's perfect. SRE is
> the better point of view to observe it.

Interesting point here as well.

------
robinduckett
I recently had an interview at a taxi firm that followed this format.

One two three pre-interviews followed by a day of 5 grueling 1 hour
interviews.

I didn't get the role. Apparently the frontend guy I had the first interview
of the days five was concerned about my technical skills.

I mean, I find it insulting, having worked for the last 12+ years as a
developer to be told that there were "concerns about your technical
competency"

I hate interviews. I hate take home coding tests and have failed every single
one I've had. Apparently this is a sign that I don't do well under pressure.

I've been building working software for years, and the main problem I have is
convincing people that I can actually do the job. I don't have a degree, and I
don't have prestigious companies on my CV, and I don't have the time or energy
to chase around roles like this, so I have to settle for unfulfilling and
underpaid roles

~~~
koonsolo
> having worked for the last 12+ years as a developer

I've done plenty of interviews, and the amount of years someone worked does
not mean they are technically capable.

By chance, last week I interviewed a frontend JavaScript expert: couldn't
explain 'scope', couldn't explain 'function context', didn't know what happens
when setTimeout() is followed by an infinite loop ("After 10 seconds or so the
browser will probably timeout the loop"). A junior cannot know everything, a
senior should be able to pull a project and team.

Personal advice to you: if you are really good but cannot show it in an
interview, try to land a job at companies with ex-colleagues, where they are
able to vouch for your technical skills.

If a colleague that I respect vouches for someone (s)he worked with, (s)he is
practically already hired.

~~~
s1k3s
> didn't know what happens when setTimeout() is followed by an infinite loop

I'm not some JS guru but I've done a few and I'm wondering why would I need to
know this? To me this looks like the type of question that is there
specifically because people answer it wrong, they know they answer it wrong
and you know they know they answer it wrong so it makes them lower their
demands in terms of pay rate.

~~~
remify
I guess it's an important question because it is about the event loop.

Lots of weird things (bugs) can happen when you don't understand how the event
loop work. I would definitely pass a "senior" javascript dev that don't
know/understand the concept.

~~~
koonsolo
Exactly this.

A senior should know that JavaScript runs single threaded with an event loop,
and therefore doing heavy calculations will block your user interactions.

If you don't know this, you also won't know when to use WebWorkers etc.

Juniors can learn, seniors should be the ones teaching them. Seniors should
define the architecture of your solution, and solve weird problems. You cannot
do this without proper in-depth knowledge.

~~~
s1k3s
Yeah but here's the thing: I do understand the event loop, I understand the
sync/async models in JS but I have very little knowledge of how setTimeout
works in this context. That's because I've never used it, and I've never used
it because the book that I read 15 years ago about JS said something like
this: "Here's a function that allows you to run some code after some time. If
you feel the need to ever use it, it means you're doing something wrong,
therefore please never use it". This very vague explanation combined the lack
of usage of it makes it pretty hard for a candidate like me to realize that
you are actually asking a question about event loops. So my question is, if
you want to see my knowledge about those things, why not ask some direct
questions about it?

~~~
koonsolo
I'm the kind of interviewer that would keep asking until you do know. I would
actually start with asking about the event loop. Don't know that, no problem,
what happens with setTimeout()? Don't know that, no problem, how does async,
await work? Don't know that, why do we need WebWorkers? What happens with an
infinite loop? How do events work? etc.

There are plenty of ways to see how this person came into contact with the
event loop concept, whether in theory or in practice.

~~~
lostmsu
Meh, I'm with previous commenter. I know what the event loop means, that JS is
single threaded, and what setTimeout is supposed to do under normal
circumstances. I consider the question stupid, moreover your answer to it is
likely incorrect, because it depends on the implementation. I bet Node.js
never interrupts the loop for example (and I never even done Node.js, it would
just be a sane thing to do).

And yeah, you might agree on Node behaving differently, but that just proves
the question is very bad. Even with "in browser" clause the answer can change
tomorrow for all we know.

It is like asking about undefined C++ behavior in an intentionally very bad
example.

~~~
koonsolo
Then please enlighten me what frontend questions you ask in your interviews.

By the way, only 1 out of 10 frontend developers can answer what the event
loop is, according to my experience.

~~~
lostmsu
I am not saying understanding event loop is not mandatory for senior JS devs.
It is just that your question is really obscure. Why not just ask what an
event loop is and what are the consequences of that execution model?

~~~
koonsolo
Some JavaScript developers know the theory, but not all of them. At least you
should know how it practically works.

So when you ask "What is the JavaScript event loop?", most will stare at you
not knowing what it is. So then I jump to the practical side. They at least
should have worked with either setTimeout, async/await and/or events. So then
you start asking for practical consequences of the event loop, such as what
happens with an infinite loop after setTimeout or await, or during handling of
an event. That is a real practical example that they should know. If you don't
then you don't know neither theory nor practice.

~~~
lostmsu
Practice can change tomorrow.

------
Rockslide
Reading that stuff always makes me feel incredibly stupid (or rather
clueless). I wouldn't be able to answer most of those questions off the top of
my head. Including this weird clock hand question (which is probably some
trivial math that might or might not have been taught to me more than a decade
ago and which I never ever actually applied since).

Then I probably have to remind myself that I'm (halfway successfully) running
a SaaS platform with tens of thousands of users, so maybe I'm not that
clueless after all.

Maybe Google scale isn't for me.

~~~
chrisseaton
> Maybe Google scale isn't for me.

Google employs the very elite of the elite. If you're working there you're
probably at the very top of your field. Obviously not every can meet that
standard and there's no shame in not being the absolute best.

~~~
onion2k
_Google employs the very elite of the elite._

I feel a little sorry for Google's developers. They're told they're brilliant
but asked to write software to deliver adverts and track people. They could
_literally_ be curing cancer and putting people on Mars if they wanted, and
yet they sit in Mountain View working out new things to do with the data about
what I clicked on today. It's a huge waste of talent.

~~~
jcahill
People who dedicate their lives to curing cancer and putting people on Mars
are titans for making verrry verrry wee little dents in those problem areas.

Your typical software engineer slept through the minimum amount of biology
coursework required of them and has no special interest in chemistry beyond
maybe like, a broscience-level grasp of pharmacology related to research
compounds commonly viewed as smart drugs.

If bay area futurism woo is indicative of broader trends among software
engineers, this person also has a vague, half-ironic commitment either to
superintelligent AI immanentizing the eschaton or brain uploading becoming a
hot-swappable replacement for the mortal coil within 20 years. Or both.

A belief that Google's workforce constitutes an addressable vat of brainpower
of such raw g that, were it not for the idle concerns of developing adtech, it
could turn to curing cancer is a very strange belief.

~~~
derangedHorse
I'm not sure what the intention of the OP was but I read it as those engineers
could help push those efforts forward by doing what they do best -- writing
software. Not all of those involved in the effort to cure cancer are studying
chemicals and making drugs. There's also people who have to run some matrix
calculations with MATLAB code, or who have to transcribe experiments into
excel sheets. It's hard to think that if we took the pool of talent that makes
the information-collecting products that Google makes, it wouldn't have any
difference in the amount of progress made

~~~
jcahill
I elaborated:
[https://news.ycombinator.com/item?id=23140556](https://news.ycombinator.com/item?id=23140556)

Parent comment:
[https://news.ycombinator.com/item?id=23124327](https://news.ycombinator.com/item?id=23124327)

------
Traster
>At first I thought I would be applying for a software developer position but
after we went through my skillset, the recruiter concluded that I would better
fit as an SRE.

I've got to say, I've been contacted by recruiters for Google a few times, and
it has _always_ been for SRE roles. I got the distinct impression that it's
less about whether my skillset fitted being an SRE, but more that they need
lots of SREs and have trouble pursuading people to take that job. I'm sure
some people want to be SREs, but Google seems to want Software Engineers to
become SREs.

~~~
nickysielicki
Why do you feel like it's less glamorous/whatever to be an SRE?

~~~
Traster
The impression I got from talking to the recruiter is that you're spending
more of your time ensuring systems work as intended and managing running
systems than you are building systems from scratch, and particularly you're
not working on the sexy parts of systems - the bits people actually notice,bu
instead are focused on making sure those sexy bits actually turn up in a
timely manner. It's not a bad thing, it's just a very long way away from what
I do, and what I want to do, and the fact that the Google recruiters are
always pushing me that way gives me the imipression they struggle to find
people for the SRE roles.

------
daenz
Ah, interview hazing, where having an encyclopedic knowledge that you can
regurgitate on command trumps all. What a phenomenal waste of time.

~~~
MattGaiser
When I first started down the path to becoming a software engineer, I never
suspected that flashcards would be part of my interview prep as though it were
a history course.

------
zapnuk
I'm probably not as driven as most people here. But I wouldn't want to have
SEVEN technical interviews for what seems to be a relatively average opening.

~~~
p1esk
For many people the opportunity to double their salary is worth spending a
couple of months solving programming puzzles.

------
Karupan
Just reading this post triggered my anxiety. I don’t think I’ll ever make it
though a single one of these FAANG interviews if at all I want to work for
one.

------
jedberg
Getting rejected by Google turned out to be great for the author. He ended up
founding a successful company instead. (Browserling)

------
southphillyman
My take away from this is that the bar may have been lower in 2008 when the
headcount was lower than it is now despite the headcount having exploded
recently. You still get the in-depth system design questions and "tech trivia"
that requires a review of the spec for whatever language/technology you
interview on, but the algo questions are harder now. Finding the unique set
and implementing a binary tree would be "lay up" questions now to most
prepared candidates. At the very least those caliber of questions have limited
ambiguity and don't require knowledge of any tricks to get optimal solutions.

------
cassalian
> Unfortunately, I just learned that I'm not getting hired.

Seems like a ton of effort to go through to not get hired. I'm curious as to
why he wasn't hired; IMO it seems kinda strange to go through 8 interviews
only to be rejected.

~~~
StreamBright
Google is notoriously bad with these interviews. Most famous case is the
Homebrew guy. I got turned down once because I haven't had a degree in CS.
They knew that in advance yet they did the whole round.

~~~
chrisseaton
> I got turned down once because I haven't had a degree in CS.

This doesn't make any sense - the employ I'm sure thousands of people without
degrees in CS.

~~~
StreamBright
Amazon took me and others, in fact, during my time one of the most senior
engineers did not even finish high school. They don't care.

------
anon7683213
I’ve passed the exact same SRE interview, well enough to be offered follow up
interviews for a higher level. I’m not saying that to boast, I’m saying this
to remind people that the celebrity developers, whose blogs and tweets we
share here, are just as good as you, and more importantly, you can be just as
good as them.

------
kureikain
Did anyone notices these questions aren't hard on algorithm sides(all
algorithm questions in this post are common/trivial) but more about
understanding Network(TCP) and Distributed System(Map-Reduce problem).

And the issue about forgoting to initalize data. Is the interview at Google
really looking for that perfect solution on a whiteboard? In an interview,
it's easy to forgot those thing like. I'm sure we have that moment when debug
something and miss some trivial thing

Anyone has done similar SRE interview recently care to share some questions?

------
threetwoone321
This is from 2008 it seems.

------
c0l0
My interview process for SRE in Dublin in 2012 went pretty much exactly the
same (procedure-wise - content was different though), and passing the on-site
interview felt hard enough that I'm kinda proud of it to this day... But I
also had to agree to not ever talk about the questions presented, in case I
ever wanted to work for them.

Now I wonder if that provision was alreay in place when that article was
written initially, and the author just doesn't and didn't care - or if it had
to be installed after such articles started popping up, and Google engineers
and recruiters felt like running out of questions people couldn't prepare for
:)

------
soygul
I like how they asked a map-reduce question. If your previous experiences
didn't involve working over massive datasets with distributed computing, you
wouldn't have a clue. But if you did your search about your prospective
position, you could find and study for the potential interview topics.

They are effectively selecting candidates who have spot-on experience for the
position in hand or are willing to put the time to study for it. Is it too
much to ask? Probably not for what you would be getting in the next couple of
years if you were to keep it up.

------
andreareina
How is "What's the angle between clock hands when it's 3:15?" a trick
question? It's not 0.

~~~
kureikain
I was asked that question 2 times in different companies. At the first time I
apparently forgot the the Hour stick will move a little bit when the Minute
stick move to 15. I guess it's a trick question when we can easily forgot that
fact. My brain is train that way that when it's 3 then the Hour stick is at
3...

~~~
andreareina
Wow it had not even occurred to me that anyone would not remember that the
hour hand ticks forward a bit every minute. Blind spots and all that. Also
just reinforces how much I dislike trivia and trick questions.

------
cdent
These sorts of interviews do not find good software developers, they simply
remove a certain kind of bad (not really) software developers along with a
whole host of very good software developers that don't fit a very specific
mold (perhaps people who write cheery blog posts about how fun it was?
...weird). Which is fine if you're the company doing the interviewing, but
completely time wasting for the interviewee. In aggregate it sounds like abuse
and disrespect. It's dismissive of experience, accomplishment and aptitude in
favor of training to the test.

People say that Google has changed their tune somewhat over the years, but
their creed has had impact throughout the industry. It's a shame.

~~~
rwmj
I'm not going to defend this style of interviewing, but I think it's useful to
have tests which filter out people who cannot program at all. If you do any
hiring you'll know that a surprising proportion of interviewees who make it to
an on-site interview for software positions simply know nothing about the
subject. When I did interviews at my start-up we'd have a Linux machine
connected to a projector for interviewees to use (this is for Linux programmer
and sysadmin positions), and a small but significant proportion of the
candidates had no idea what to type into the terminal to list files, or what
an absolutely trivial program (like loop to 10 printing numbers) did.

~~~
cdent
Sure, can't dispute what you say. There has to be some amount of "you must be
this high to ride this ride" but you don't need to measure 7 times or whatever
before thinking the first measure was accurate.

I've been on both sides of the interviewing tables many times and the
processes that worked the best were the ones that involved telling stories to
another another and seeing how the other reacted. You know, actually
interviewing, humans having a conversation.

------
newbie578
Ah screw it, I'll be the boy in "the emperor's new clothes". Google sucks!
They try to put themselves on cloud9 and look at us "mortals" like we should
be grateful for 8 interviews, LOL.

Age has caught up with them, they just refuse to acknowledge it. They are no
longer the "hottest" company on the planet yet they keep behaving like they
are.

To me personally, Google has become tne old IBM, a giant tech behemoth who
cannot move normally and is riding on a single product and old glory.

I would rather work at Microsoft right now than at Google (although I am aware
I don't have "qualifications" for neither"

------
dijit
I'm going to copy my response from a related thread 2 months ago:
[https://news.ycombinator.com/item?id=22405372](https://news.ycombinator.com/item?id=22405372)

\---

I interviewed at Google for an SRE:Systems role around a month ago; I can
share my anecdotes.

The first interview put me in contact with a recruiter who would basically be
my guide throughout the process, at first he asked me some basic questions to
feel out where I was weak and then told me to prepare those weaknesses for the
next round.

The next round was 2 phone interviews, lasting about an hour each and over
different days, one focused on my programming skills (of which, I have little
because sysadmins don't typically do anything relating to data structures) and
the second one was surrounding linux internals and debugging (which I was very
strong on).

I spent roughly 2 working days worth of time preparing for them.

Preparing for the on-site was pleasant, I was put in touch with another google
recruiter who ensured I knew where I was going and what I was doing, they told
me that I'd be there the whole day and while they couldn't tell me what I
would be asked/who I would meet/what to prepare; they gave me an approximation
of the _kind_ of questions, very broadly.

I spent roughly 18 working days preparing in my weak areas, including
leetcode/data structures and reading comp-sci papers (paxos and ilk).

On the day, I went through about 5, 1-hour long interviews that focused on
various aspects of SRE (one of them being 'googliness'), some were about
distributed systems (where the interviewer got hung up on the fact that I said
I would use postgres instead of making my own database) and others were
heavily programmer focused (linux internals was more about knowing the
implementation of 'ls', scripting was all about the kinds of questions you get
on leetcode).

I'm not going to lie, it was gruelling, and I'm typically pretty comfortable
interviewing;

I thought I'd be fine with these interviews because I'm considered to be "shit
hot" in sysadmin/writing glue by my peers, but I guess not, as I'm not a
Google-SRE. :)

(sidenote: everything in TFA rings true, including the tips, google recruiters
are quite transparent about your process. But they also said that the last
stage is not the interview, it's roughly 5 hiring committees that are looking
at your application "package" through different lenses)

~~~
pansa2
> ‘googliness’

What does this mean? How do they evaluate whether someone is sufficiently, um,
Googley?

~~~
dijit
They explained that; it's coded word for "culture fit", but it's used as a
verb inside google (one example: "Sorry, that wasn't very googly of me").

It's the idea that you're expected to be open to feedback, empathise a lot and
be always willing to go above and beyond to help someone.

I actually passed that one. So, I think it's just a jerk test. I think they
asked me about if someone was stealing my credit, or the credit of others-
what would I do.

------
jpistell
Seven interviews seems a bit... abusive?

------
mnd999
So how much of that stuff do you actually do day-to-day?

~~~
cbanek
Yeah seriously, it seems like a lot of the questions revolve around the TCP
stack. Maybe it was a more networking type job?

~~~
pansa2
It doesn’t seem unreasonable for an SRE position. Presumably the focus of the
interview would be quite different if you were applying to work on, say, V8 or
the Go compiler.

------
bauerd
Whenever I read about people's interview experience with Google it sure sounds
more stressful than my actual day job. I understand investing the time when
youre a new grad, but I have no idea how already employed people find the time
to prepare for these interviews …

------
simonebrunozzi
My job interviews at Amazon (2008). [0]

[0]: [https://medium.com/@simon/2008-how-i-got-hired-by-amazon-
com...](https://medium.com/@simon/2008-how-i-got-hired-by-amazon-
com-314ee8634da9)

------
sys_64738
There are three types of developer. Those who never worked at Google, those
who currently work there, and those who used to work there. The third kind are
the ones to avoid if you're interviewing for your company.

~~~
rsanek
So you can interview current Google employees, but not former ones? Why?

------
jstewartmobile
I doubt they do the eight-separate-interviewer hazing to people with public
achievements. Who would stand for it?

" _Go calculate the angle, Linus._ "

~~~
rsanek
If you consider homebrew a public achievement, then yes:
[https://mobile.twitter.com/mxcl/status/608682016205344768?la...](https://mobile.twitter.com/mxcl/status/608682016205344768?lang=en)

------
rossmohax
For the reference, thats from 2008

------
known
Sounds like a Quiz, not Interview :)

