
Google Interview University – Plan for studying to become a Google engineer - jonbaer
https://github.com/jwasham/google-interview-university
======
pjlegato
Google's sort of "computer science trivia" style interview is the bane of
software engineering.

"CS trivia" interviews select for people who know the mathematics of computer
science, not for people who know how to ship robust software systems on time
and within budget. The two are only loosely related and mostly uncorrelated.

In the real world, you use a well-tested premade off the shelf library to
traverse a DAG or implement a red/black tree. Just because someone can recite
algorithms and data structures in their sleep doesn't mean they can
effectively scope, plan, or execute a complex software dev project; and
conversely many of the best engineers either never learned or long ago forgot
the details of the CS.

This mode of interviewing is like interviewing the contractor you're
considering to remodel your bathroom by handing them a pile of iron ore and
asking them to smelt high grade structural steel out of it.

So why do they do this? Lack of any better option. Their previous
"brainteaser" style interview didn't work at all, and this is probably
marginally better than that at finding good engineers. But more importantly,
it's much cheaper and faster and less risky in terms of confidentiality than
hiring candidates as temporary contractors for a real world test doing actual
work, which is the only remotely effective way to tell who is actually a good
engineer.

~~~
dragonwriter
> In the real world, you use a well-tested premade off the shelf library to
> traverse a DAG or implement a red/black tree.

Unless, you know, you are implementing the standard library for a new
language, so that there is no such "off the shelf library" available. Which
its not been completely unknown for Google software engineers to do.

"Off the shelf libraries" aren't things that are handed down on stone tablets
to the prophet on a mountaintop, they are things that are created by software
engineers.

In any case, understanding _which_ algorithms and data structures to use, even
if you are using a pre-made library, and the impacts of that decision requires
an understanding of the algorithms and data structures similar to that which
is needed to implement them (it doesn't strictly require the ability to
implement, but ability to implement isn't an unreasonable way of filtering for
the requisite knowledge.)

~~~
Periodic
When I worked at Google Search Infrastructure (not any ML stuff) I actually
built a performant, persistent red-black tree implementation in C++ for
creating persistent sorted lists with good insert and delete characteristics.
It's was a pretty niche need, but we had it and the existing libraries we
could find didn't cover it. We needed it for doing some speculative programing
where we were doing some constraint solving and were using a greedy-ish
algorithm to explore the constraint space. Arbitrarily solving the constraints
was theoretically and practically impossible in a performant way, so we
settled for a greedy exploration of the search space but we needed a way to
back out of failing lines of exploration.

So, yeah, we needed engineers who were strongly familiar with the theory of
how hard things are to solve and knew a lot about different types of data
structures. We were in a space the existing libraries didn't really cover.

Maybe not all engineers need these skills, but it was valuable that our team
all had them and were thus able to have deep design discussions about it.

The skill that's lacking the most at Google is project management, which is
not necessarily a skill that every engineer needs.

~~~
kabouseng
I would argue the exact opposite, more engineers need basic project management
knowledge than algorithm knowledge, perhaps even at Google.

------
falcolas
This is a bit meta, but it bothers me sometimes how much virtual ink is
spilled on how to pass algorithmic interviews. Especially considering how
little of your career will actually depend on the knowledge being presented.

I'm slowly learning that despite how much more money I've earned by skipping
between companies, skipping is not a path to knowledge. It provides better
earning opportunities (to a point), it provides new challenges on a regular
basis, but I've lost the ability to go deep into a topic. The depth that can't
be achieved in two or three years.

I guess I'd really like to see a bit more ink spilled on "congratulations, you
got a job; now what?" What interpersonal skills are most important? What are
good resources for continued learning? What do C level people actually do? How
can I help the company succeed? What career opportunities are possible for me
without having to skip jobs? What can I learn from this company before I go to
create my own?

That would be much more valuable, IMO, than a primer on how to pass an
interview process.

~~~
eloisant
You're probably right, but there are probably millions of software engineers
who can have a successful career at Google. But they won't get in unless they
can pass the algorithmic interviews.

I agree that the emphasis Google puts on algorithmic interviews is a bit dumb,
but that how their hiring system works. So anyone who really wants to get a
job at Google needs to work on that, regardless on whether it will be useful
inside the company or not.

~~~
falcolas
Are there really millions of engineers who will have a successful career at
Google, or are there only a hundred or so every year?

There are millions of programmers, most of which will never get a job at
Google. Is their time perhaps better spent optimizing their existing careers
instead of doing "dumb" things for a chance at the gold-plated goose?

~~~
mattnewton
Most things I do in my day to day work are dumb. I code around browser
incompatibility, write scripts to automate parts to byzantine and stupid
buisines workflows away that survive for political reasons. Etc etc. The point
is that if a few months of studying is underneath you, modern software
development is going to have far more stupid schlep anyways; I imagine
especially at a company of google's size.

------
iskonkul
While we could debate on the meaningfulness of his goal, I find the person
admirable. We could perhaps award more credit to the fact that this is a 44
year old person who is taking the difficult course of going through the
material of CS on his own and then setting a clear goal to aim for. And of
course not forgetting to celebrate his virtue of learning for life.

~~~
yodsanklai
People complain about Google style of interviewing but I like the idea that
you can at least prepare for them. I'm sure there are many companies that
wouldn't even consider because you're too old or because you don't have the
right background.

~~~
stale2002
Yeah, I have a suspicion that this is the only reason why people still use it.

The signal that it is measuring is "How much did you prepare to get this job."
Which isn't that bad of a signal.

------
ipsin
I used the same approach last time I was interviewing -- keeping a wiki of
"everything I knew or sort-of-knew about computer science" and then trying to
fill in the gaps.

At a glance, a few things I would throw in are:

* UTF-8 (a basic understanding of how wide characters are encoded)

* streaming algorithms

* lock-free data structures (what they are and why you probably shouldn't implement one)

In some sense it's like trying to hold the entirety of CS in your head for one
day. You might spend 30 minutes learning about something so you can mention it
as an aside. But... I think it's worth it, more for the knowledge.

Knowing that something is possible (e.g. encrypted search) opens doors in the
same way that working cross-discipline can.

~~~
rz2k
I like the idea of using a wiki to track a lot of concepts you've learned. How
do you keep track of everything that is in the wiki? Do you have a front page
that is organized like an outline, or maybe a long list of concepts?

~~~
ipsin
I went with the "long list" approach -- it was just a single page.

------
martiuk
While joining Google is probably the last thing I want to do, this is a
perfect resource for someone who hasn't had a formal education in computer
science.

~~~
guessmyname
Indeed, I have no degree but have been working for +7 years in the field.
Recently I decided to start searching for new challenges but thanks to ATS [1]
my resume has been rejected 90% of the time, the other 10% has been invested
in interviews in fairly popular companies including Amazon and Booking.com.
After having studied CtCI [2] and practiced on LeetCode [3] for two weeks
_(yes, just two weeks)_ I was able to pass most of the technical interviews,
so I can testify that using this repository as a way to improve your skills
actually works.

PS: Just to clarify, I haven't been hired by any of the _" Big 4"_ yet, but
that is because — again — I have been studying for only two weeks, if I invest
more time on this, maybe in 5-6 months I can guarantee an offer in one of
those popular companies that appear featured on HN all the time. And as the
parent comment says, even if you have no intention to work for Google or any
other of the big corporations, this still is a good list of resources to
improve your skillset.

[1]
[https://en.wikipedia.org/wiki/Applicant_tracking_system](https://en.wikipedia.org/wiki/Applicant_tracking_system)

[2]
[https://www.amazon.com/a/dp/0984782850](https://www.amazon.com/a/dp/0984782850)

[3] [https://leetcode.com/](https://leetcode.com/)

------
fgblanch
More than a Google interview university this is the curriculum for an online
degree in computer science. Thanks for sharing.

------
OJFord
This seems like a great set of resources, but getting as keen as [0,1] just
seems like the author setting himself up for disappointment.

[0]: [https://github.com/jwasham/google-interview-
university#get-i...](https://github.com/jwasham/google-interview-
university#get-in-a-googley-mood)

[1]: [https://github.com/jwasham/google-interview-
university#follo...](https://github.com/jwasham/google-interview-
university#follow-me)

~~~
adrianm
I also feel bad that he has seemingly tied up so much of himself into this.
Although the technical interviews at Google kind of require this prep, at the
end of the day interpersonal skills and other factors contribute to the final
decision as well. It's possible someone interviewing him will find this
distasteful. It's also possible someone might just not like him. It's
impossible to know exactly what will happen, I just hope he's somewhat
psychologically prepared to not be offered a job.

~~~
AlexCoventry
Even if he doesn't get the job he's going for, mastery of that curriculum will
be tremendously valuable. So it's a pretty benign delusion, as long as it's
motivating him to study.

~~~
OJFord
I think the parent commenter was agreeing with me; I certainly wasn't
suggesting the resources are or time spent learning them is a waste.

It's specifically the "future Googler" print-outs, and plethora of usernames
and websites that include "Google" that I think could make it a heart-breaking
rejection. (Though of course, I wish OP all the best and hope it doesn't come
to that!)

Frankly, I can also imagine it being more than a little embarrassing after a
successful application.

------
UweSchmidt
Great ressource! Thanks for making this public.

"If you like this project, please give me a star. "

So it's "like, comment, subscribe", and now "give me a star"? It's the first
time I've seen this and I hope this doesn't catch on. The current system of
aggregation/curation/voting works fine imo.

~~~
wodenokoto
A github like is a star. Or is there something I've misunderstood?

~~~
mixedCase
The system is not the problem. It's the solicitation.

~~~
solutionyogi
I don't get it. Why is the solicitation a problem?

It's a different thing if he says that you must STAR before you can access the
repo.

~~~
whorleater
I think it's a merit thing. If your content is truly worthwhile, is there a
need to solicit/ask for stars? Researchers don't beg people to
"like/comment/subscribe/star/tweet/etc" in their abstract, it feels odd to ask
for a star in this manner.

------
sotojuan
A lot of people will get turned off by the idea of having to or wanting to
study so much just for a job at a company. The way I see it though, this is a
great list of resources to learn about a lot of programming-related things.

~~~
samfisher83
Google pays pretty well. You have to spend so much time in school getting a
degree and if you spend some extra time getting this job well as incremental
cost it isn't too bad.

------
kornakiewicz
Good list of resources, but motivation to have a job in certain company seems,
for me, like wrong approach. What if Google won't be the place you would like
to work after two years (because something happens in your life, or at
Google.) Or after few months of employment you got feeling it's not place for
you?

This motivation also won't make you a better person.

~~~
jimbokun
Interviewing at Google gives him a specific target to motivate his efforts,
but the material he is learning will be very useful to interviewing at other
places as well.

------
sulam
Google people regularly tell me that qualified candidates have a 50/50 chance
to make it through the interview process successfully. I'm sure they're
working on that, but I would be thinking about it in those terms.

~~~
samfisher83
If you don't prepare the probability is much less than 50/50\. I would rather
have prepared and failed then just go it there and bomb it. You are going to
have waste a day going to interview might as well be prepared.

~~~
pjlegato
That's kind of the point -- _even if you prepare well_ , your chances are only
50/50, so don't be too disappointed if you don't make it.

~~~
gnator
These interviews are no different than a lottery where you hope and prey they
choose an algorithm question you studied and learned well

~~~
babygoat
A recruiter at Google literally told me which algorithms to know study and
learn well, and only one of them came up in interviews (DFS).

------
yborg
Where is the university for engineers that want to _replace_ Google, not work
_for_ Google? Because working for Google is basically like working for IBM
back in the 1970s.

~~~
TheDrizzle43
Spend your time building shit instead of reading Cracking the Coding Interview
and wasting time on Hacker Rank / Leetcode. There's the university.

------
CrypticSplicer
I like your list! I'm going to give it to my little brother before he applies
to work for Google. One thing I'd recommend looking into is deep search with
pruning. It's nothing terribly clever- just boxing up something you've
probably done before and giving it a name. It's a problem solving technique
that often has tremendous real world benefits. Essentially- if you can take a
problem and define it like a tree with potential solutions on the leaf nodes,
can you define a search on that tree that gets you to the right solution as
fast as possible? Often simple tricks can help you chop off entire branches of
the tree so you never having to waste computation exploring them.

It's nothing revolutionary, but its good practice to be mindful of when you
can chop pieces off of your search space. Interviewers always love hearing
something like "and if we organize the problem this way, we can always stop
searching here because we know we can't get a better result".

P.S.- If you know python I'd recommend interviewing in that. You won't be able
to implement anything with nodes very well, but you can write most code on the
whiteboard very succinctly. They WILL want to see actual code.

------
kp25
I would start doing this from today, Not for getting a Job in Google, but to
become a better software engineer.

\- Thanks for the Amazing List of Resources

------
morgante
How is this not an indictment of Google's interview process?

I have a CS degree and many successful software projects under my belt. Plenty
of employers have happily paid me to ship software for them and I have
repeated referral customers. I have no doubt that if given my computer and
access to the internet, I can easily implement any algorithm in this list.

Yet I also have no doubt that I'd have to prep for at least a dozen hours
before a Google interview if I wanted a chance to succeed.

Why on earth should going through a software engineering interview require
pulling out your old textbooks and running through problems? Since this is
really just a glorified IQ test, I'd much rather they just handed my an IQ
test (or asked for my SAT).

------
guru110
Looks great even for just refreshing the basics again. Great work. Thanks.

------
astrange
If you like, I can forward you my emails from their recruiters too. They're
starting to get a little passive-aggressive since I never reply to them.

~~~
toast0
They stopped emailing me when I told them they were mailing the wrong person
with my name. It helped that they were actually trying to reach someone else,
they referenced "my" experience at a company I've never worked for, and I
found a blog post for that company by another person with my name.

------
edgyswingset
This guy's website is weird. Feels like he's fetishizing Google the company.
Not that there aren't people who do that, but still.

------
supervillain
You'll get into Google if you have a CS degree plus good in memorization.

memorization != understanding, I hope Google should give chance to the latter
being the "time-tested proven" engineers which some can't answer "computer
science trivia" because most of them don't spend time memorizing theories,
they spend their time building and applying what they learned.

------
Yhippa
This is a very ambitious list. It basically describes what you would end up
going through in a CS undergrad curriculum (as others have pointed out).
Personally it takes me a while to initially learn something and keep probing
my understanding until I feel I have a solid understanding. There is so much
to learn in this list I'm not sure how someone could reasonably understand
most of these things without it taking quite a bit of time. I know for me if I
tried to go through this list from top to bottom that the stuff I learned
first would start to fade from memory as I kept adding more stuff at a rapid
clip.

------
hal9000xp
There is a flaw in this program and in many coursera courses about algorithms
and data structures.

Although, you can relatively quickly grasp all basic algorithms and data
structures, you most definitely can not quickly build up skills of recognizing
these algorithms in problems (which is most valuable skill and most
overlooked).

Another problem is that you also forget these algorithms pretty quickly and
can't implement them after a few months.

I was on and off in algorithms since 2014 and already experienced these
problems during last two years.

Now, I took another route which is much slower but now, I can remember,
recognize and implement some algorithms after a few months.

I started to participate in algorithm contests, mainly on CodeForces,
sometimes on HackerRank. Often these problems cover pretty narrow topics and
what you can learn in two months on Coursera, on CodeForces you can learn in
one year or even more.

Why algorithm competitions is useful? When you stuck on the problem for a
while, then you read solution and you see that this problem is solved [for
example] by Dijkstra algorithm, you remember this algorithm for a while. If
you stuck on another problem, and then after reading solution you discover
Dijkstra algorithm again. You remember this algorithm for very long time
(provided you put significant effort to solve the problem). That's because
your brain connects Dijkstra algorithm with some important problem because you
are frustrated solving this problem during contest. So frustration is actually
good for memorization! (if used correctly).

So there are 3 aspects which you should develop together in order to achieve
really good results:

1\. Implementation skills;

2\. Problem solving skills (i.e. how you recognize algorithm in the problem);

3\. Knowledge of algorithms, data structures, paradigms (like dynamic
programming, greedy etc);

Often courses covers only third aspect.

Here is my description of CodeForces problems difficulty and relevant skills
they develop:

Div2 A - trivial implementation problem, train accuracy;

Div2 B - little tricky but still trivial problem, find little things to solve
the problem;

Div2 C - sometimes easy, but sometimes really hard to solve, covers topics:
combinatorics, dynamic programming, greedy, elementary graph algorithms etc;

Div2 D - usually hard to solve, but can cover classical algorithms like
Dijkstra, Kruskal's, binary indexed trees etc;

Div2 E - very hard to solve, way above my current level (the same applied to
Div1 problems);

If you can solve Div2 C problems consistently within 15 minutes and sometimes
solve D problem within 30-45 minutes, you will crush Google interview (at
least their algorithms + data structures part, which is where most people
stuck!).

~~~
gniv
I wish your comment were higher up. It does indeed take time to internalize
how to use these data structures, and that's what the interviews usually test.

------
sp527
If you're already a successful entrepreneur, the only reason you'd want to be
a Google software engineer is if you have no idea what you're signing up for.
There's absolutely nothing magical about working at Google and the learning
curve plateaus fast, at which point you're likely a salaried code monkey. If
that's more money than you anticipate making on your own, then I guess go for
it. Otherwise you're making a serious mistake.

------
crispyambulance
Maybe its just me, but it sounds like the OP is setting himself up for
profound disappointment even (and perhaps especially) if successful.

All that time and energy focused on becoming an employee of that one company,
Google, will create enormous expectations which are likely to be crushed by
reality when the OP comes to the realization that, yes, even Google is just
another place to work for a living. Does anyone who actually work there think
otherwise?

------
potbelly83
Why are people so obsessed at working for Google? Granted, I'm sure there are
a few niche groups which are probably really cool to work in, but the others
probably involve their fair share of CRUD work, like any other typical large
corporation.

------
iblaine
This is a great list of fundamentals for CS.

This is also very creepy.

------
arez
Would be nice to have such a list more data science, database orientated,
maybe someone knows of a similar list.

~~~
paulgb
I think this is what you're looking for
[https://github.com/datasciencemasters/go](https://github.com/datasciencemasters/go)

------
partycoder
It is fine to create a training program targetting top tier technology
companies. No problem with that so far.

But he specifically mentions Google. That I have a problem with: you cannot
advertise a program as an being effective approach to the Google interview, if
you have not been an interviewer, or you have not received an offer as a
result of the interview process.

------
desireco42
I don't think any corporation deserves this kind of attention.

I did notice that Indian and Pakistani engineers like to do those kinds of
preparations, and reasons are mostly cultural.

You should always come prepared on the interview, but the better engineer you
are, more companies and options you will have.

------
sunilkumarc
This list is really huge! Do we really need to learn all of this?

------
geebee
I don't really object to content of these exams any more than I'd object to
taking the math and linear algebra exam if I were an actuary, or the bar exam
if I were a lawyer. I certainly don't think this is all trivia. It's
foundational, but not the sort of thing developers walk around ready to be
tested on in their day to day lives. If you suddenly plunked a vector calc or
numerical analysis exam in front of a senior actuary, many of them would
probably fail, even though they all passed the test at some point. If you
suddenly forced experienced lawyers to re-take the bar exam, many would fail,
including those who did very well on the bar.

Trees, graphs, mathematics, binary? Sure. It's foundational.

What I dislike about these "interviews", so much that I have contemplated
leaving the field, is that we, as developers, have to take them over and over
again, under capricious and arbitrary circumstances.

Think about all the exams I mentioned above. They have a proper study path,
they are administered consistently, they are graded and evaluated by respected
and vetted professionals who will at least _attempt_ to apply similar
standards. You get information about what will be tested, you get feedback on
how you did. You don't spend studying and preparing only to hear "we've
decided not to pursue your (actuarial candidacy/bar candidacy/nursing boards)
at this time".

That's what makes this all so awful. I feel, after 15+ years, that I've re-
taken my fundamentals exam enough times. If it were trivial, that'd be fine,
but it takes time and focus to get ready for it, time I'm less and less
inclined to spend on it.

I think that there is an informal set of rights and responsibilities that
evolved over time between exam-based professions and students. I believe that
the "tech interview", which is really an exam, has almost all the downsides
and none of the positives, none of the protections that evolved in the other
fields.

The only positive thing I can say is that at least tech doesn't require a very
specific degree, unnecessarily long, that can only be obtained by going
through certain accredited programs that cost $40k+ a year in tuition (the 3
year law degree at sky high tuition that can _only_ be obtained through
certain programs is cartel-like, professional regulatory capture at its very
worst). But you know, actuarial exams are rigorous, don't require a specific
degree, you can prepare how you like. I'd say that's probably the best model
for software.

I don't mind studying for this, but I don't want to have to do it over and
over, and I'd like some assurances that it will administered properly.

------
jamisteven
FML I could not imagine prepping for something like this.

------
ksk
Isn't it kind of perverse in a way that all this CS talent is going towards
supporting a company whose primary purpose is to mine your data and create
profiles about your habits and needs?

------
omarforgotpwd
also check out interviewcake.com

------
exabrial
I once really wanted to work for Google, but after my in person interviews I
realized I would never fit in. I was instantly judged for my soft Midwestern
accent and dress shirts, while the guy in skinny jeans and explained to me
that Java's HashMap.get() was not 0(1) and asked if I was taught that in my
non-Stanford education. (It is btw, feel free to analyze the implementation)

For a place that claims to be culturally diverse, I realized there was a
hidden list of acceptable cultures, and mine was not one of them. I politely
declined the offer and decided to stay a bit closer to home.

~~~
rand_r
Totally pedantic, but no HashMap.get function is O(1). In order do a look-up,
you have to compute the hash, whose size is at least log2(n).

~~~
dahart
The reason hash computation is traditionally called constant time is because
it doesn't change while the hash table grows. Big O describes how run time or
memory consumption grows as input grows, and with a hash table, the hash
computation typically does not grow.

Calling a hash table O(log2(N)) gets misleading when you measure a hash
function's performance, and it doesn't change as the table grows.

So you're right about your technicality, but you're using big-O slightly
differently than how everyone else is using it.

The implications are interesting, in that if the hash computation did grow as
O(log2(N)), then it would (theoretically) outperform the current typical O(1)
hash table implementation, and they would meet only when the table is full.

Another way to see O(1) is that hash computation is always implemented not as
a log2(N) function, but is log2(MAX_N), where MAX_N is the size of a full
table, and since MAX_N is a constant, the complexity is O(1).

A side note is that not all hash tables are implemented using an array that
can hold N items. Some hash tables use linked lists instead of re-hashing for
collisions, meaning that your array can be arbitrarily less than N in size,
meaning that it is definitely possible to have a hash function that takes less
than log2(MAX_N) time. In that case, insertion time becomes explicitly greater
than O(1).

~~~
bogomipz
I'm not following your logic here:

"The implications are interesting, in that if the hash computation did grow as
O(log2(N)), then it would (theoretically) outperform the current typical O(1)
hash table implementation, and they would meet only when the table is full."

How would O(log n) ever out perform constant time, O(1)? Could you elaborate?

~~~
dahart
This is and always has been an important part of understanding what big-O
notation actually means. O(1) means constant time, it does not tell you what
the constant is. The constant can be large.

In this case, if your hash always takes 64 bit values and always produces 64
bit values, it is O(1). If your hash were O(log2(N)), then your hash function
with an empty table would do 1 bit worth of work, and would do only one
operation. But when the table grew to contain 1,000 elements, it would do 10
bits worth of work.

The O(log2(N)) algorithm with N < 2^64 is always faster (in theory) than the
O(1) algorithm that does a constant 64 bits of work.

The O(1) algorithm pays off in spades for N >> 2^64, it will become much
faster than the logarithmic one, but for small N, log(N) is smaller than 64.

~~~
bogomipz
Right, a constant i.e unchanging amount of work.

I usually think of hashtables though as being O(1) in referring to the look
up(amortized) and not the hash code itself.

~~~
dahart
Yep, and a hash table's get is O(1) amortized even when you include the hash
function itself, simply because the hash function doesn't change as the hash
table grows. @rand_r is right that the hash function is doing C * log2(MAX_N)
operations, but that doesn't actually affect the big-O metric, it only affects
the run time. :P

~~~
bogomipz
Indeed, thanks for the clarification.

------
pjlegato
[https://en.wikipedia.org/wiki/Correlation_does_not_imply_cau...](https://en.wikipedia.org/wiki/Correlation_does_not_imply_causation)

~~~
sctb
We detached this subthread from
[https://news.ycombinator.com/item?id=12653059](https://news.ycombinator.com/item?id=12653059)
and marked it off-topic.

------
sagivo
nice info. i built something similar in ruby for my interview, focusing more
on the coding part -
[https://github.com/sagivo/algorithms](https://github.com/sagivo/algorithms)

------
lkmslkmdfsd
Saddest title I have read in a while. I don't think being a disposable screw
in a corporation X is anything great.

