
Algorithms Interviews: Theory vs. Practice - jakevoytko
https://danluu.com/algorithms-interviews/
======
fyp
> a friend of mine once got a Google Code Jam World Finals question in a phone
> interview with Google (...) I doubt there were more than a few hundred
> people in the world who would've gotten the right answer to the question in
> a phone screen and almost all of them probably would've realized that it was
> an absurd phone screen question

Link to the question:
[https://code.google.com/codejam/contest/2437491/dashboard#s=...](https://code.google.com/codejam/contest/2437491/dashboard#s=p2)

The gist of it is: You are given 4*N points on a 2D plane. Can you draw two
perpendicular lines to separate them into N points per quadrant?

I think Dan's missing context is that google code jam questions always have a
small and large dataset. In this case, small is N=10 which makes a lot of
bruteforce solutions possible and not much different from any other bruteforce
puzzles common in interviews. Being a geometry question is the more unfair
part if this is a generalist role (but not unfair if your role involves
graphics, computer vision, self driving car mapping, etc).

Expecting a solution for the large (N=2500) is ridiculous of course. See
analysis:
[https://code.google.com/codejam/contest/2437491/dashboard#s=...](https://code.google.com/codejam/contest/2437491/dashboard#s=a&a=2)

~~~
chillee
Another piece of contextual information that's important is that interviewers
can provide hints during an interview.

For example, I was asked this question once: Given N points and 3 squares of
side length L, what's the minimum L that allows you to cover all N points with
the 3 squares?

I think this question is fairly unreasonable as an interview question, if you
weren't given hints. In the context of an interview, however, I think it could
be reasonable.

~~~
majke
A similar situation happened to me, and the problem was not hints. I just
wasn't happy with that particular problem because I knew how much time it took
me the last day, when preparing, to solve it!

I was really not into doing it again, it was so traumatic.

The correct curse of action is for the interviewer to anticipate this and
prepare a backup question.

------
Ozzie_osman
> When I ask people at trendy big tech companies why algorithms quizzes are
> mandatory, the most common answer I get is something like "we have so much
> scale, we can't afford to have someone accidentally write an O(n^2)
> algorithm and bring the site down".

I think people who say this just don't get what's really going on here. If you
look at these types of interviews, a big part of what they select for is: 1)
Some sort of problem-solving skill that's a mix of raw intelligence and/or
ability to solve problems by pattern-matching to things you've seen before. 2)
Ability/commitment to work on something that may not be that intrinsically
motivating, in the context of getting/maintaining a certain type of job.

These interviews select exactly for that. To pass, you usually have some mix
of: \- raw intelligence. \- ability to pattern match to similar problems
you've seen before. \- ability and motivation to spend time preparing for
these types of interviews, even if they're not really what you care about
doing.

That's really what they're trying to capture. It's not a perfect filter (you
will still have some false positives and plenty, plenty of false negatives),
but it works "well enough".

You really only need one Dan Luu per like 10 or 100 engineers at a FAANG. Most
people aren't going to be optimizing at the level he is, they're going to be
doing work that's mostly a mix of problem-solving by pattern matching, and
ideally, they're motivated enough to have that job for as long as possible.

~~~
barrkel
I think most interviews are designed to find people similar to the
interviewers, whether they realise it or not. If you think it works "well
enough", I think you're just fooling yourself.

I say that as someone who has gotten a job offer from every interview I've
been interviewed, and done maybe 100 on the interviewer side of the table. I
put far more weight onto pair programming and anything that resembles a work
sample than anything else. And even then you don't really find out what people
are like until like the tenth pull request or so.

~~~
Ozzie_osman
Getting an offer from every interview is impressive, good for you (you don't
cite how many but I'm assuming you've done a good number in different
contexts). Even the smartest people I've known have had mixed luck with
interviews, due to some combination of randomness, poor interview design, or
just poor fit for that company. As for administrating 100 interviews, you'd
prob rack those up in a 2 year stint at a FAANG (usually they'd start you
around 6 months in or earlier and you'd do 1-2 per week thereafter).

Anyway, yes, interviews are prone to bias. So are work samples (in different
ways). Pair programming can be better but logistically harder (i don't know
any companies that have been able to do them at FAANG scale), but even then,
like you said, you'd need a lot of it to really judge.

At the end of the day, the entire hiring process needs to work "well enough"
and with reasonable cost to both company and candidates. For many FAANGs,
these interviews (plus hiring committees, bar raisers, or something else) meet
that criteria... Though honestly, they often fall short on diversity but
that's a whole other topic.

~~~
barrkel
I'm 40 (ouch!) and I've done about 6 serious interviews - other conversations
over lunch and whatnot, that I didn't pursue - I'm not a serial interviewer,
granted. Three job offers I declined.

Where I work today, I'm in the last round of interviews, to try and reduce the
time consumption.

My real point is that a work sample is really hard to get in an interview, and
it's really not fair to fire someone in their evaluation period because
they're only average, and not extraordinary, with what they come up with in
day to day work.

~~~
sibeliuss
_Friendly reminder that 40 is not old_

------
Infinitesimus
> Some companies will give very large out of band bonuses to people, but that
> work wasn't for a company that does a lot of that kind of thing, so there's
> nothing the company could do to indicate that it valued additional work once
> someone did "enough" work to get the best possible rating on a performance
> review. From a mechanism design point of view, the company was basically
> asking employees to stop working once they did "enough" work for the year.

and

> This also happened in another way. As is common at a lot of companies,
> managers were given a team-wide budget for raises that was mainly a function
> of headcount, that was then doled out to team members in a zero-sum way.
> Unfortunately for each team member (at least in terms of compensation), the
> team pretty much only had productive engineers, meaning that no one was
> going to do particularly well in the zero-sum raise game. The team had very
> low turnover because people like working with good co-workers, but the
> company was applying one the biggest levers it has, compensation, to try to
> get people to leave the team and join less effective teams

are pretty important points to note.

Accepting that organizations are incentivized to extract the maximum amount of
value from you means you should be: 1\. Aware of the value you produce 2\.
Know how to sell it

This also comes up during promotion season in places that require that you
perform at 50%+ of the next "level" to be eligible for a promotion. The unsaid
part is that you will be under compensated for that 50% "next level" and when
the promo comes, you'll be at the bottom of the comp band at the new level (no
wonder people tend to quite shortly after a large promotion)

~~~
closeparen
> to try to get people to leave the team and join less effective teams

From a director-level perspective it probably makes sense to have one or two
of your best people on each team, rather than some wholly excellent teams and
some wholly mediocre teams.

~~~
crtlaltdel
From the standpoint of providing skill-mentorship opportunities it makes
sense. A few strong engineers on a team can really help everyone grow.
Naturally personalities and preferences should be accounted for, however one
of the best moves I ever made was to break up a "ninja squad" (what they
called themselves) of high functioning devs when their big project wrapped up.
The squad was small (3) and each person was very well liked by the entire
engineering team (13). We had several green-field projects starting up, so
none of them felt banished to the salt mines of legacy maintenance tasks for
instance. The general quality and velocity improved across the teams and we
gained more consistency in our codebase when it came to patterns.

------
boulos
So, amusingly, my referral hit rate at Google is like 1/10\. Worse, I _only_
refer people if they've told me that they're certain they wish to go through
the terrible process.

When I say 1/10, I don't mean 10%, I mean I have entered about 10, and only
one got an offer. In my opinion, all were qualified and should have been given
offers. For comparison, I've done roughly 100 interviews or something (though
not nearly enough SWE interviews, because I'm in San Francisco). As an
additional _upwards_ bias, I actively discourage people from applying, so this
is only the folks that said "I understand, refer me anyway".

All that said, Google is really more like dozens of independent companies now.
There's Search/Ads, YouTube, Cloud, Photos, Android, Maps/"Geo", and so on.
Your mileage will vary pretty drastically depending on how you're routed. Just
like Dan was misdirected towards a software interview, I've had friends tossed
into the _SRE_ hiring pipeline, asked how to operate large-scale distributed
systems and so on, when their background is "Umm, I just did my PhD in CS in
Graphics... I've never written a networked program in my life".

To all the other Google employees: find the job posting internally that your
friends would _actually_ want, talk to the hiring manager to figure out what
that maps to externally on the job postings page (it often doesn't), and then
tell the assigned recruiter that you're serious about your recommendation. The
recruiter may still override you in deference to their hiring targets / goals
though (the one offer I've seen from my referral went this way despite my
effort), so don't promise your friends that you can fix it for them.

I'm not here to excuse these hiring practices. Instead, be honest with
yourself about why you want to apply, and how much hassle you're willing to
put up with. In my experience, all other companies will decide more quickly on
your hiring result, role, level, compensation and so on. I _believe_ that's
because of the scale of the interviewing and hiring (>10k full-time employees
per year for the last few years), except it's always been pretty bad at
Google.

~~~
Google234
lol, it's actually much worse than that.

------
aphextron
>"I’ve done maybe 40-ish "real" software interviews and passed maybe one or
two of them"

I'd say that about mirrors my experience as well. Is this really that common?
Here I was thinking that I'm just an idiot.

~~~
ping_pong
I'm almost 50. I pass about two-thirds of all my on-site interviews, but have
100% failed my FNG interviews (I got an offer from Amazon 15 years ago but
declined because I didn't want to move to Seattle). I've failed Google 4
times, Facebook 3 times, and Netflix twice. I think my biggest problem is
because I'm so old, their expectations are even higher than what I
realistically am. I'm okay being hired as a "senior software engineer" and
working my way up, but they insist on interviewing me as a staff level, which
I clearly am not capable of achieving. I'm confident that if I were to get in,
I would perform in the top tier of engineers, but it's those damn algorithm
questions I just can't get past.

~~~
thatsenough
"Almost 50" means you're in your 40s. And you probably started interviewing in
your mid-40s, at the latest, if you've already interviewed 4 times.

The gist of your comment might be correct, but I think we shouldn't perpetuate
the mindset that mid-40s or even 50s is "so old."

In almost all knowledge-worker professions, age and experience is acknowledged
as an asset. I think software companies are just _starting_ to realize that,
as the "move fast and break things" companies are now weighed down under
technical debt and imposing hiring freezes on recent grads and junior
engineers.

I feel like I'm in my prime in terms of experience and productivity, and
though I may not want to work 70+ hour weeks or chug beers at the office
anymore, I'm a considerably better engineer than I was 20 years ago. I think
many of us intuitively know that, and we shouldn't let ourselves become victim
to self-defeating SV groupthink.

~~~
ping_pong
I started interviewing at Google since about 2005 so over 15 years. I've seen
the entire gamut of interview style questions, from trivia questions, to brain
teasers, to easy algorithm questions, to the algorithm arms-race where
LeetCode hard questions are now being asked. It has only gotten harder and the
expectations as someone with 25+ years experience is too much. That is the
biggest problem someone my age faces. I'm easily the best programmer on the
team, but it's hard to show when I can't memorize 400+ LC questions for the
FANG interviews.

------
dehrmann
> The most widely read programming blogger around (Joel Spolsky) was telling
> people they need to adopt software practice X because Microsoft was doing it
> and they couldn't compete adopting the same practices.

These days, it's amazing how much "We do X because Google does X" you see. But
Google is the new circa 2003 M$, so it makes sense.

~~~
gmiller123456
>"We do X because Google does X"

My standard response was "The most distinguishing property of Microsoft
(Google) is they have a monopoly, copy that part first".

------
jorblumesea
I actually suspect that one of the main purposes of the algo based interview
process is a motivation check. It takes time to prep for these interviews.
Lots of time. So if you get a candidate that is crushing problems, it can
either mean two things:

1) They are exceedingly brilliant and they can program decently

2) They have studied hard, they can reason and code decently

Combine that with a system design portion and some behavioral questions, and
the company is probably getting a solid hire. Does it mean that you're weeding
out some false negatives? Absolutely. But large companies don't care. The
system works well enough, and until it doesn't, I doubt much will change.

~~~
PretzelFisch
I still see it as an age experience filter the further you are form college
the harder and more prep time is required to bring up seldom used skills
backup to proficiency.

------
kris-s
> At one point, after getting a promotion and a raise, I computed the ratio of
> the amount of money my changes made the company vs. my raise and found that
> my raise was 0.03% of the money that I made the company, only counting
> easily quantifiable and totally indisuptable impact to the bottom line.

Would profit/revenue sharing help with this?

~~~
dehrmann
Except supply and demand drive your pay, not how much you make the company.
Now, if you can't make the company at least as much as you cost, then you're
out of a job.

Those "I made the company X" arguments are only interesting if it was an
action/idea that you were uniquely responsible for. If it's something most
equally qualified people would have done in that role, it's not that
interesting.

~~~
amznthrowaway5
Even if you were uniquely responsible and it’s something extremely difficult
hat few could accomplish, there is no way to prove it and the company usually
treats you just like any other idiot hired at your “level”.

~~~
chii
if you have such unique and powerful skill that you can attribute to this
level of value production, then your only option is to found a startup and
extract 100% of that value from said skill.

------
christiansakai
Its hard to believe that Dan Luu can’t pass algorithm interviews.

~~~
TrackerFF
It has a lot to do with psyche. If you have anxiety, it is entirely possible
to even fail the most basic questions. And unfortunately, you can't just say
"Sorry, I'm having a panic attack. Could we do this tomorrow?".

I think the best course is anxiety management. But unfortunately, some people
get dependent on drugs just to calm their nerves before something important. I
know people that can't hold meetings or presentations without taking beta-
blockers and the likes.

~~~
wesleyac
Just FYI - in many interviews, you can just say "Sorry, I'm having a panic
attack. Could we do this tomorrow?". One of my friends had a panic attack
during her Google interview, left came back the next day, and got the job.

So, YMMV, but people are often able to be accommodating for things like this
:)

------
insighter
Does anyone have articles or advice/experience to share on improving a
company's interviewing process / culture? I work at a medium/large enterprise
software company in SFBA that's well compensated (not quite FAANG level) and
sometimes a final round interview will have 5 algorithm style whiteboarding
questions which feels excessive and lazy.

I'm interested in:

a) standardization. Right now interviewers pick their individual questions and
sometimes the question types. You can't apply a wildly inconsistent measure
across anything and expect to have confidence in your findings.

b) interview question diversity. If people have varying strengths and our day
to day work goes beyond just solving algorithm style questions (because it
does for a huge majority of dev jobs) then a more diverse body of questions
seems to be a better yardstick to measure others by. Examples of questions
types that seem interesting to add include refactoring existing code, pair
programming, small coding project and even weird things I haven't heard of
before like the ability to give constructive feedback on design proposals,
etc..

------
yibg
This topic comes up pretty often, and I think most people agree algorithm
interview questions aren’t effective and screen for the wrong things. The
question though is, what is a better way to interview? I don’t think I’ve seen
any consensus, let alone anything backed by data yet.

~~~
sdnlafkjh34rw
You could ask coding questions that are not algorithms? Realistic problems
that are commonly found in web work.

------
gowld
Opening statement:

> When I ask people at trendy big tech companies why algorithms quizzes are
> mandatory, the most common answer I get is something like "we have so much
> scale, we can't afford to have someone accidentally write an O(n^2)
> algorithm and bring the site down"

In 20yeara I've never heard someone say anything like that.

~~~
wolco
If we are one query from bring down the site I don't want to be anywhere near
that site.

~~~
izacus
If you haven't had a single query bring down a service at least once, you just
don't have enough industry experience with services.

It's surprisingly easy to bring down complete complex services system with a
unlucky degenerate case.

~~~
sgerenser
Like A site wide outage at StackOverflow being caused by an inefficient
backtracking regex engine: [https://stackstatus.net/post/147710624694/outage-
postmortem-...](https://stackstatus.net/post/147710624694/outage-postmortem-
july-20-2016)

------
fakename11
Eh, a lot work at Google is pretty heavy on algorithms. It's important to know
how to write high performance code and algorithms and data structures
knowledge is a large part in that.

