
Hacking a Google Interview (2009) - astdb
http://courses.csail.mit.edu/iap/interview/index.php
======
csnewb
All I do at work is fix bugs by changing a few lines of code and glue together
API's to send data from A to B. I don't regularly search BST's using DFS/BFS
algorithms or find the kth shortest string in a merged unsorted linked list or
some shit like that. Preparing for these technical interviews is like a part-
time job after my full-time job.

~~~
andrewprock
For the most part these interviews are not meant to evaluate the quality of a
candidate, rather they are meant to evaluate candidate interest.

~~~
rco8786
That’s not remotely true. (Source: have administered hundreds of these
interviews)

~~~
andrewprock
IIRC, the published results were that above a certain bar, there was no
predictive value to interview results. Having interviewed many dozens of
people, and been in dozens of interviews, I can confidently say that the
current standards of technical interviews do not screen for quality, but
interest.

The whole point of having someone study typical problems to the point where
they can solve them in 30-45 minutes is not to demonstrate quality at the job.
Rather it is to have them signal that they are interested in doing the things
they need to do to get hired. Those types of problems are outside the scope of
software engineering, and getting good at them requires a significant
investment in time.

Yes, they will reduce the rate of false positives somewhat, but greatly
increase the rate of false negatives.

~~~
rco8786
> the published results were that above a certain bar, there was no predictive
> value to interview results

What I said is not exclusive to this research. These types of interviews are
not great, but there's no other "accepted" way and a lot (most?) companies are
afraid to try new stuff because making a bad hire is very expensive.

> they will reduce the rate of false positives somewhat, but greatly increase
> the rate of false negatives.

In addition to what I just mentioned above, the companies that invented and
stick to this style of interviewing are well aware of and don't care about the
false negatives. Their desire is to reduce false positives and they have a
mile long line of willing candidates behind that person if they get a false
negative. When you interview at Google/Facebook/etc, your recruiter will tell
you that a lot of people don't pass the interview the first time. And if you
don't pass, they'll reach out to you again in ~6 months to see if you want to
try again.

The companies that use these interviewing processes that _don 't_ have a large
pipeline of candidates are doing themselves a huge disservice IMO. But kind of
like "nobody got fired for hiring IBM"..."nobody got fired for copying
Google".

------
dweekly
Good SWE interview tips. For those interested in product management interviews
at Google I wrote some guidance at [https://hackernoon.com/acing-your-product-
manager-interview-...](https://hackernoon.com/acing-your-product-manager-
interview-e4f163408cef)

Context: I'm on the Google PM Hiring Committee and help craft our hiring
rubrics.

~~~
oil7abibi
What are your thoughts on doing PM right out of school? I interned at Msft as
a PM and SWE. Now I’m trying to decide between the two rolls.

~~~
dweekly
Congrats on having good options!

Several companies (including Google) have very good associate PM (APM)
programs that offer recent grads rotations through a few different roles,
mentorship, and a strong peer group. Several APMs end up with rapid upward
trajectories at the company and many decide to jump into starting their own
companies but it is rare to come across people who did this and regret it.

Some people go into industry or consulting for a bit, get an MBA, and then
join directly as a PM. Another popular route (the one I took) is to be a
startup founder and learn what works and doesn't on your own terms directly
from your own customers.

SWE and PM have very different lifestyles - a PM's day is slammed with
meetings and most of your output is email, presentations, spreadsheets, PRDs,
dashboards...a SWE's day is more focused on code, ops, design docs - fewer
interrupts and more focused. But you likely know this as you've lived both
realities already! My advice would be to think about which path suits your
disposition and to solve for joy, learning, and impact.

~~~
rishsharma
Unless you are a TL. A lot of overlap with PM work but more eng execution
focused.

------
rajathagasthya
These are useful tips, although the example questions are extremely outdated.
I found one tip "interesting" though.

> If you already know the answer, don't just blurt it out! They will suspect
> that you already knew the answer and didn't tell them you've seen the
> question before. At least pretend to be thinking though the problem before
> you give the answer!

Most interview questions are taken from sites like Leetcode. So you would have
come across some of them if you work through those problems. Is it really that
bad if you give the solution quickly? Some problems have specific "techniques"
to solve them which you would likely only know if you solved it before. Are
you expected to come up with a completely new algorithm to solve a problem?

~~~
aphextron
> If you already know the answer, don't just blurt it out! They will suspect
> that you already knew the answer and didn't tell them you've seen the
> question before. At least pretend to be thinking though the problem before
> you give the answer!

Ah yes, deceit and trickery, the basis of any solid future working
relationship.

~~~
watwut
It is absurd that instead of correcting own bias against people who happened
to randomly run across exactly the same problem, they advice you to pretend
ignorance.

------
partycoder
I suggest this book the Competitive Programmer's Handbook
[https://cses.fi/book.html](https://cses.fi/book.html)

~~~
lalwanivikas
Have you read it? If yes, how does it compare to other books specifically
meant for interview prep like CTCI, PIE etc.

~~~
partycoder
CTCI puts an emphasis on interviews whereas this book is only about
competitive programming.

CTCI tries to make interviews about competitive programming, this book is
about competitive programming itself.

CTCI offers some high level problem solving advice, and a list of exercises.
This book elaborates provides a framework for understanding the exercises and
elaborates on techniques for each type of data structure.

------
Apocryphon
Can any interviewers at Google or any of these large corporations share about
how the interviewing process has changed in the last few years as now Cracking
the Coding Interview, HackerRank/CodeWars/LeetCode, Glassdoor, mock interview
sites, and even interview-prep bootcamps have become part of the curriculum
for potential candidates to prepare for interviews? Do the companies find it
as absurd as the candidates do?

~~~
baseethrowaway
Not an interviewer in Google, but have been in Google.

I've read CtCI, used the mentioned and/or other websites for problem solving
and have had 10+ interviews on pramp.com and interviewing.io, both as an
interviewer and interviewee.

Due to my experiences and experiences of other people that I know, my
conclusion is that the interviewing process has not changed. Google has a pool
of thousands of questions, so you likely did not hear the questions that
they'll ask you before coming there, unless it's the question to establish
whether you're a programmer at all or not (phone screen). Like learning to
drive -- you don't go out and memorize every road by heart, but learn how to
act on the road and interpret situations, signals and signs. Those resources
shouldn't teach you the questions, but teach you how to really be you in an
interview and perform at your nominal level.

After going through the above resources, my impression is that they have
helped me type faster, make less mistakes in boilerplate and think more about
the problem when it's given, before diving into it. Certainly, I do remember a
few "tricks" more than I used before going through them, but overall, I think
they've helped me very little with the problems in interviews and more with my
behavior in interviews. The pattern that I've always seen is that intelligent
people who code well pass the interview more often than not and that less
intelligent people and/or those who don't code well don't pass ever.

------
sanj
I taught the class for several years; I'm happy to answer questions.

Or point folks to some notes from an updated version of the class.

~~~
dominotw
I get really nervous with timed interviews, ticking clock freezes my mind.

Wondering if you have any tips for that.

I code in java at my day job but its not really well suited for whiteboard
interviews where I have write all this code on the board. Google interviewer
was noting down what I was writing on whitboard and said that he will compile
the code after the interview. Wondering if you have any thoughts about it,
maybe choose something more consise like ruby?

~~~
sigjuice
Why not compile and run the code during the interview? IMHO it should be way
faster than writing stuff on the whiteboard and will save the interviewer the
trouble later.

------
sreeprasad
This is 9 year old course. Still good for practicing.

"The class is held in room 32-124 from 5:00-6:30 PM on January 12 - 15, 2009"

~~~
solarkraft
I'm rarely this late ...

------
informatimago
Given the turn-over at Google is barely 2 years, what's the point? (And it's
the largest of most companies too, so, you see what I mean).

~~~
askafriend
That's because whatever statistic you pulled doesn't account and adjust for
Google's growth which is massive in the past couple of years. If a majority of
employees are new hires, then they haven't been there for 2 years and that
drags down the average....

We need to stop repeating these statistics with no context. It's incredibly
misleading.

~~~
polishTar
Yep. The attrition rate is not even remotely close to 50%. My recollection was
that this turnover rumor started with a stat that at one point in Google's
recent growth, the median tenure of the employees was only 2 years. This stat
then got interpreted (and then reported) by some as Google having an obscenely
high turnover. Of course, you can't get turnover rate from median tenure,
they're completely different things.

If the size of a company doubles in a year, the median tenure will be <=1yr.

If the most junior employees of another company start quitting en mass, the
median tenure for the remaining employees will actually increase.

Median tenure is a completely useless in determining how many people are
leaving a company.

------
lawrencewu
I run a (paid) newsletter that sends fun coding interview puzzles every day.
If you're interviewing around (or if you just enjoy programming problems),
check out Daily Coding Problem:
[https://dailycodingproblem.com/](https://dailycodingproblem.com/)!

~~~
blinkingled
You should've mentioned that email address is required and solutions are $25 a
month. But other than that good idea if the actual puzzles and solutions are
valuable.

~~~
lawrencewu
You're right, I updated it to reflect that it's paid. I think email address is
implied by the newsletter though.

I'm obviously biased but I think the problems are fun and the solutions are
valuable. Here are some blog posts I wrote that hopefully give you an idea of
our questions:

Given a table of currency exchange rates, determine whether there is a
possible arbitrage: [https://dailycodingproblem.com/blog/2018/01/02/find-an-
arbit...](https://dailycodingproblem.com/blog/2018/01/02/find-an-
arbitrage.html)

Picking a random element from an infinite stream:
[https://dailycodingproblem.com/blog/2017/11/30/random-
elemen...](https://dailycodingproblem.com/blog/2017/11/30/random-element.html)

Merging k sorted lists: [https://dailycodingproblem.com/blog/2017/11/29/how-
to-solve-...](https://dailycodingproblem.com/blog/2017/11/29/how-to-solve-
coding-interview-problem.html)

