
Ask HN: What is the point of algorithm-heavy interviews? - groomed
Who really cares about algorithm on daily bases. How often you solve algorithm-heavy tasks at work?
======
seanwilson
> Who really cares about algorithm on daily bases.

I find that statement really depressing to be honest. Why would you be so
happy to deprive yourself of a huge source of potentially useful information
that is the foundation of our field that shouldn't take long to learn?

Algorithm and data structure knowledge helps you write processor + memory
efficient code that scales well, and stops you reinventing the wheel when you
know how to classify what category of algorithms your problem fits into (e.g.
it's a graph problem, or a search tree problem, so now you know where to look
for solutions).

You might not need this knowledge every day but someone who understands
fundamental algorithms and data structures surely has an edge over someone who
does not. If you've been programming for a while, going through a book to
learn the fundamentals should only take you a few days as well - why do people
make such a big deal about this?

I've interviewed programmers before who couldn't explain what a linked list or
a hash table was, and when you'd you use one of those over an array. To me,
that's a super bad sign they don't know how to assess algorithmic complexity
when coding. It might not matter for some kinds of coding with modest datasets
but it'll bite you eventually.

~~~
theshrike79
This is like saying that a car mechanic needs to have a PhD in thermodynamics
to work on internal combustion engines.

99.9% of coders just need to know what things in their chosen language(s) are
performance sensitive and what aren't - very few actually need to know the
exact reason why. And even fewer need to be able to improve on said
algorithms.

If something needs sorting, you call the sort function in the object. There's
absolutely no need to know what algorithm it uses, the only thing that matters
is that the end result is sorted correctly.

~~~
steev
It is far from saying that. At best it's more like saying a car mechanic
should understand how a car works (e.g., how does an internal combustion
engine work) even though most car mechanics spend 80% of their time changing
oil, oil filters, and rotating tires. I think it is completely reasonable that
a car mechanic should understand how a car works because without that
knowledge how do they diagnose what is wrong?

My main issue with this topic is everyone seems to complain at the difficulty
and ridiculousness of the process yet proposes no viable alternatives. No one
likes the idea of take home projects/coding assignments. People write blog
posts complaining that they shouldn't have to do side projects to give
themselves a portfolio. So what is left? Just the resume? That doesn't seem
fair to people coming out of school or career changers that have no experience
- how do we evaluate them? We can't ask them anything related to CS.

~~~
bradleyjg
Work sample. Do you spend any parts of your days writing syntax clean
implementations of complex algorithms on a whiteboard with no access to
references? Because no one I know has a job anything like that.

Knowing enough about various algorithms to suggest different ones and their
trade-offs in a brainstorming session when presented with a (vague) problem is
something that actually happens in some jobs. That part is fine to simulate in
an interview if it’s an important part of a particular job.

What most software engineering interviews should have but don’t are sections
on fixing bugs and adding features in existing codebases. These are the bread
and butter of a lot of jobs. But that doesn’t allow for interviewer dick
waiving, so it’s pretty rare.

------
throwaway_009
I realized that everyone needs a base level of algorithms knowledge to write
and design good software. Ideally it is pretty basic (leetcode easy), but the
initial employees at FAANG companies decided to have a hazing ritual by
creating increasingly complicated questions (e.g. leetcode hard) and it is
exacerbated by a large number of kids from universities who mindlessly play
this game. It spread to all other tech companies too and the process is just
destructive.

I don't see an end to this. Its as if all companies expect people to be
competitive programmers, and they optimize only on one parameter :/

~~~
dillonmckay
The rules of the game seem to be well-known at this point.

If one desires a job at a FAANG, it is fairly clear what ‘skills’ are expected
to be demo’ed during the interview process.

It is as flawed as the SAT for college admission, but again, the individual
knows what to focus on to maximize a successful outcome.

~~~
throwaway_009
Since the rules are known, the threshold has increased so much that people
don't see any issue when leetcode hard questions are common place.

I have seen multiple instances where the interview questions are ridiculous by
any sane terms. It incentivizes gaming the system by just getting good at
algorithms and not building up other skills.

Just as an example, look at Google as a new user (without any brand context).
The design is terrible, the product management is terrible, the hideous search
bar everytime you open the android home screen, etc. all in my opinion caused
by optimizing for one attribute in 99% of the hires. It causes them to think
"oh well the data says people don't mind the change", but you can't track the
growing discontent of the customer base. And you are a monopoly so don't have
to give a shit about UX anyways.

------
jefftk
I've interviewed a lot of candidates (~200), and my interview generally looks
like:

* I describe the problem

* They ask questions to figure out parts I didn't specify (which lets me evaluate how they handle resolving ambiguity)

* They propose a brute force solution, and I ask them how quickly it runs and how much space it needs (talking in big-O is a fast way for me to tell if they understand their solution)

* They propose a much more efficient solution (often with hints) and we again talk about time and space complexity (which again lets me see whether they understand how to compare solutions like this. I'm also happy to hear other tradeoffs like "this is optimal but too complicated to be worth maintaining")

* They code their solution (which lets me see if they can actually code, and check how well their description of their algorithm matches their actual algorithm)

This isn't a daily job sort of task, but it's not far off, much faster, and
very information dense. I'm not testing "do you know the right algorithm" (and
will hint that part).

~~~
booleandilemma
Am I allowed to check stackoverflow during your interview process?

~~~
jefftk
I agree that ability to look things up is a major skill, but testing it
reliably is difficult since it's so high variance.

So, no, I don't let people use reference materials including stack overflow.
But I'll answer questions, and not judge them harshly for things that would
easily be looked up.

------
nprateem
To waste your time.

> Who really cares about algorithm on daily bases. How often you solve
> algorithm-heavy tasks at work?

Practically no one and practically never for the majority of developers.

It's a trend started by Google, and since lots of startups don't bother
thinking for themselves (and the interviewer wants to sound knowledgeable)
some of them also ask these questions.

Perhaps this type of interview is more popular in some places rather than
others - I've never had one like this, although occasionally people ask
questions like "how many piano tuners are there in your city?" (answer: "let
me check on Google..." or "why, are you thinking of starting a piano tuning
company?").

~~~
kgraves
> let me check on Google...

First of all, Newsflash! that's illegal in a programming interview, please
solve this question using a whiteboard instead, show a mathematical proof if
needed.

/s

------
EnderMB
To create a barrier to entry that weeds out over 90% of applicants.

IMO, this is the sole purpose of algortihm-heavy interviews. Companies like
Google can put out a job ad and receive thousands and thousands of applicants,
and the sad truth is that many of them could probably do the job that is
required of them.

By putting in a loose requirement around what is essentially problem solving
via known algorithmic techniques that you'll rarely ever use in day-to-day
life, you can both weed out most applicants and ensure that the developers
that perform the best aren't looking for an insane pay packet. After all, if
you can stack rank yourself purely in programming ability, you've probably got
an impressive CV and a body of previous work that means you probably don't
need to work at FAANG or Microsoft to create something incredible.

I'd probably also say that there is an element of ageism, purely because older
people have more responsibilities, and ultimately are more willing to spend
time in the office over strictly working 9-6.

~~~
mping
I'd just like to add that is easier to compare candidates using algorithm
challenges (you can check if the candidate reached the optimal solution, how
long it took and so on).

I dislike this kind of interviewing because you miss the chance of hiring
people that are different from your regular hires, but hey the FAANGs are
doing great so who am I to criticize.

~~~
clarry
> I'd just like to add that is easier to compare candidates

But you might just be comparing one's ability to feign smarts versus another's
ability to work out a problem from first principles. Comparing apples to
oranges might be easy but the results may or may not be that useful.

This remains one of my favorite ancedotes:
[https://news.ycombinator.com/item?id=17106291](https://news.ycombinator.com/item?id=17106291)

------
patatino
I once read it is a form of ageism because older people, in general, don't
have as much time as young people due to family to study for those interviews.

Absolutely no idea if that is true but I think it is an interesting thought.

~~~
riffraff
but someone who is old would have studied this repeatedly if they applied to
multiple interviews of the same kind, so they would have internalised
knowledge. Also it's sort of timeless knowledge that you can acquire on the
job.

If anything interviews about the latest hip technology seem more prone to age
selection to me.

~~~
bradleyjg
A new job every six months was not the pattern ten years ago. Also, back then
you would have been asked why manhole covers are round instead of write a bug
free implementation of A* on a whiteboard. Neither of those are timeless bits
of knowledge that one acquires on any job, other than maybe job interview
coach.

~~~
abraCadabstrax
Is it to keep the cover from falling in the hole?

------
11235813213455
It evaluates someone's capacity to approach a complex task

It's like in school, you learn many things, not necessarily useful in your
daily life, but you learn to learn, and that's what they can see when they
confront you with a challenge

Of course, some people who heavily train for this have maybe an advantage,
like in school exams.. Personally I never specifically trained for an
interview, I just like algorithms, doing some leetcode.com challenges when
I've time is a pleasure

~~~
groomed
The problem is that knowledge needed for exams is needed for exams only, and
does not correlate with your overall expertise.

~~~
mav3rick
I can assure you algos and data structures are a big part of systems software.
Without these it's impossible to write efficient and correct code. It is these
fundamentals that have made me easily switch profiles from VR to Self Driving
to Cloud.

~~~
walterstucco666
I think it is often much better not to write them yourself, but rely on a
battle tested implementation.

Of course we're not talking about left-pad here, but implementing your own
Diffie Hellman key exchange from scratch is usually a very bad idea.

~~~
mav3rick
No one is asking you to write them yourself. But it is important to know when
Quicksort becomes quadratic. Or when separate chaining in a hash table can
lead to linear look ups. I find it abhorrent that this thread thinks these
things are unimportant. Just use a "Library". How about you know your stuff .

~~~
groomed
> I find it abhorrent that this thread thinks these things are unimportant.
> Just use a "Library". How about you know your stuff .

How about the fact that "your stuff" is not algorithm. In 99% "your stuff" is
to pick the right library

------
baron_harkonnen
People complain about algorithm heavy interviews a lot but I honestly think
they're pretty useful for several reasons (some are beneficial to the person
interviewing as well).

Even though we many software engineers aren't doing challenging enough work to
require algorithms work daily (though, wouldn't you _want_ to be doing this
kind of work?) algorithms problems have a lot you have to do. Even if you
don't use a linked list every day, designing a linked list and searching it
isn't really different than designing a User class. The difference is it will
take a few features of iterating on a User class before you bump into design
issues where these will pop up right away.

And even though people complain about not being able to code without an IDE,
frankly this is a red flag. I've seen candidates white board weird code (lots
of semicolons, or no returns in python) that makes it pretty clear they don't
write a lot of code.

Finally, white boarding algorithms questions are nice for interviewees because
you can study one topic that will apply equally for multiple companies. Take
home projects are great, but you have to do a unique one for each company. You
can practice leetcode every night and you're preparing for a wide range of
places all at once.

~~~
nprateem
> not being able to code without an IDE, frankly this is a red flag... that
> makes it pretty clear they don't write a lot of code

Muscle memory is real. Plus as a polyglot I find the context helpful for
jogging my memory for how to do something in a particular language.

I had to google how to declare a variable in Go the other day, but I've
written 10ks of lines. I'd had a break and was confused with Python. Oh well.
I'd have failed on several of your whiteboard red flags.

Bar none, what I most want to see as an interviewer is someone's own code on
GitHub. But I can count on one hand the number of times I've ever seen that
after 10 years of hiring :-(

~~~
clarry
> Bar none, what I most want to see as an interviewer is someone's own code on
> GitHub. But I can count on one hand the number of times I've ever seen that
> after 10 years of hiring :-(

I would also love to see my own code on GitHub (well, perhaps another platform
but anyway). Unfortunately having a full time job as a software developer
leaves too little time & energy for my own projects, and work stuff at my
current place will probably never land on GitHub. :-(

------
mgaw
For me there are two reasons:

(1) We want to hire people who are able to solve programming-related problems.
Now how do you find out if a candidate can do this? Looking at their CV
doesn't tell you much. You can build up a long impressive CV without being
able to program. So it would be nice to see them solve a problem right here
and now.

Ideally, that would be a problem of the type you would often encounter in your
actual work. But there are few programming-only problems in my work. And the
hard ones are about designing a larger part of a system, or fitting something
new into the context of something old, or trying to understand some old code
to be able to adapt it.

My point is: All of these take a massive amount of context into account.
Giving a candidate all that context would take weeks.

An algorithm challenge works because it has a good ratio of "time it takes to
explain the problem" to "the problem is actually non-trivial to solve".

(2) We do these algorithm questions on a whiteboard, with one interviewer also
standing and talking through the development of the solution with the
candidate. I believe this gives me a sense of whether I can and want to work
together with the candidate either on an actual whiteboard when sketching
solutions to problems or when pairing.

~~~
rimliu
I think you are mistaking a programming-related problem for a CS-related
problem.

~~~
mgaw
Hm I would say writing an algorithm is both programming-related and CS-
related.

------
muzani
Someone here once posted that they realize that it has little to do with work,
but they don't have time to test work related things. Plus candidates hate
coding challenges. So the algorithm is the closest to it.

It has a lot of false negatives, but companies like Google have so many
candidates it doesn't matter.

I liken it to military push ups. Someone who can do a lot of them also has
good enough physical strength to do all kinds of physical work.

~~~
caseymarquis
Except most people are trying to hire distance runners who will be lifting at
most 5 pounds (~2.5kg).

~~~
ratsimihah
You could argue lifting 5 pounds running long distance demands a lot more
energy than lifting 5 pounds and dropping it. And I'm sure they carry a lot
more than 5 pounds of gear.

~~~
gotts
I believe what caseymarquis meant is not the amount of energy throughput but
the kind of activity.

Marathon runners and sprint runners are both runners but they literally have
completely different muscle structure.

So developers are judged by how well they do "sprint run" when they actually
are supposed to be "marathon runners" on a daily basis.

~~~
ratsimihah
Oh thanks for putting me back on track (get it get it?)

Nice analogy!

------
gaogao
It correlates with programming ability, especially for more junior candidates.
More senior candidates can show their skills via system design.

Alternatively, you test if people can glue APIs together or really know web or
mobile dev, but backend work really does need a level of algorithmic
competency.

------
bradleyjg
They make the interviewer feel really smart, since the interviewer already has
the answer to his own question. Each interviewer should be required to go
through the process himself (single blind) every six months. Bet you’d see a
lot of no-offers.

------
mister_hn
To cut older people from fresh graduates and then offer fresh graduates lower
wages.

------
onion2k
Algorithms in interviews happen when people who enjoy writing algorithms get
promoted to positions responsible for hiring.

------
olingern
I think the HN crowd goes 50/50 on this. One half hates it and the other
believes it's a necessary evil. And then there's the small minority that
enjoys it.

I was apart of the former half who hated algorithms until I was tasked with
help hiring people. The only thing I believe that is worse than an algorithm
is me spending 8+ hours of my free time on a "take home" problem. So, I used
pretty easy to solve algorithms alongside real problems I had solved recently
for interviews.

Being on the other side as the interviewer really made me see the value of
algorithms. It becomes a medium where candidates can convey competency. I
think it has gotten murky due to the lines between a web developer and
software engineer blurring. That statement alone can be a can of worms.

Anyway, I would say algorithms / data structures for backend development _do_
come up when laying the groundwork for a new project or something that might
see a lot of traffic. Lots of things in development model certain data
structures (queues, stacks, graphs, etc.) so knowing them allows you to
converse with your co-workers and conceptualize them to others. Probably comes
up somewhere between 2-5% of the time. Design patterns probably get brought
more as their a bit more applicable for everyday tasks. It really depends on
who you're around, how challenging the work is, and what the engineering
culture is like.

~~~
nprateem
> It becomes a medium where candidates can convey competency

I really struggle to see how regurgitating something someone's read/heard
about something they didn't invent/modify conveys anything beyond memory.

------
cyberprunes
If you understand data structures and algorithms then, in my view, it
demonstrates that 1\. You recognize the importance of understanding the
principles and foundations of your field. 2\. You understand that knowing the
fundamentals isn't about "writing algorithms everyday", it's about growing
your ability to think deeply and creatively about a problem without constantly
flailing around in ignorance.

I often hear that learning algorithms / data structures is pointless these
days because it encourages reinventing the wheel or it wastes time. I believe
the opposite is true. People who are ignorant will keep reinventing the wheel,
they just won't realize they are doing it and how poorly they are doing it.

Learning algorithms and data structures will enhance your ability to write
software because you will have a deeper understanding of how things work. When
you understand how things work you can build interesting things.

Of course, if you just want to be a non-contributing faceless code monkey at a
corporation where you don't matter and get a decent paycheck well, you
probably can skate by in mediocrity. If you want to be able to build things
that don't rely entirely on the work of others that actually understood what
they were doing then you need to put in the time. The return on that
investment lasts a lifetime.

------
gorbachev
Often the problem isn't phrased as "please implement algorithm X", but "solve
this business related problem that requires use of algorithm X". The expected
answer is the same, though...you're supposed to implement algorithm X.

I've failed these sort of interviews by suggesting I'd rather find a well
tested library and use it than implement the algorithm on my own. What's the
point really.

------
bb88
For FAANG and other companies with large data: Yes. For solving actual scaling
issues, it makes sense for any candidate to understand this stuff.

Bottlenecks matter. And the better you are at algorithms means the less rework
that needs to happen.

If on the other hand you're doing day to day business logic, no, it does not
make sense. 80% of all jobs are like this.

------
inertiatic
Most people care for algorithms in some capacity in their day jobs.

Some might be able to exclusively tackle tasks that don't require algorithmic
knowledge, but this severely limits their options on what tasks they can pick
up in a team.

I haven't worked with an incompetent developer that was an algorithm wiz. And
I haven't encountered a developer who's skills I would envy that wouldn't have
known a lot about algorithms.

Is using a whiteboard the best way to hire or even the best way to test these?
I don't believe so.

But to go the extra step and claim just because perhaps in your line of work
you don't use something daily it's useless? That's asinine. To make an obvious
exaggeration: a pilot doesn't handle emergency landings on a daily basis,
perhaps ever in their career, but if I was hiring a pilot to fly my plane you
damn well know I'd try to find out whether that's a skill they possess.

------
GuB-42
I don't write algorithms on a daily basis, but is does account for a
significant fraction of my work time.

Some algorithms I have written:

\- List A and list B have common elements, go from A to B with a single
insertion, deletion and reordering operation.

\- You have two dates/times, get the number of working hours between the two,
with business hours and holidays taken into account.

\- Various forms of dependency management: we need to run an operation, that
operation needs other operations to run first, themselves having their own
requirements, etc...

\- Decode a character string where each character is 6-bit wide.

\- Have a set of data with different periods. Generate a schedule with a
major/minor cycles. The algorithm has to understand things like 333ms = 1/3s.

\- And many smaller things I don't remeber.

Most of the time, it fits in a single page, it is no big thing, I am not
trying to prove P=NP here. Just that there isn't an already written library
for every problem on earth. And even if there is, it may require a truckload
of dependencies you'd rather avoid or it may not fit your particular problem
without a lot of messing around. Or it might just be poorly written and
unsupported, libraries are written by people with a wide range of resources
and skill levels.

Algorithms are part of the job, if you don't know the basics, it will affect
your productivity. I've seen people struggle for days on basic problems,
hopelessly struggling with libraries. Or after great effort, come up with a
broken solution that will need to be redone eventually.

Of course, algorithms are not the whole picture. But if a coder can't do it,
there is at least one aspect of the job he lacks. And it turns out that it is
easy to test for in an interview. Proper design is more important, but it is
usually apparent only after thousands of lines have been written and
requirements have changed several times, not something that is easy to test
for.

------
skyzyx
There are pros and cons. Interviews are inherently imperfect. I’ve interviewed
people who can do a bubble sort algorithm off the top of the heads, but cannot
figure out how to use GitHub to save their lives. I’ve interviewed people who
write great code, but can’t articulate their ideas well enough to sell them to
management.

Both soft + hard skills are mandatory. Hard skills are probably 33%-50% of the
job, while working with people and being able to solve complex human problems
in engineering is 50%-67% of the job.

Interview with algorithms or not — I don’t care. But don’t think for one
second that an ability to write code is the only important part of being an
engineer.

------
new_realist
Algorithmic interviews test for intelligence. Everyone prefers more
intelligent and capable developers. At the end of the day an interview is a
competition; the job goes not to any qualified candidate, but the best
qualified.

------
d--b
The question is: what mistake should the developer not do?

A bad developer will not implement properly the separation between
infrastructure code and business code.

A bad developer does not care about readability, so the code will be laden
with functions that have side effects, and things of that nature.

A bad developer does not comment their code in a meaningful way.

None of these are easy to find out in an interview. It turns out that
questions about algorithms are good proxies to find people who are interested
and proficient in computer science.

Sure you will miss some good developers that aren't good at algorithms, but
there is a better chance that you do not hire bad candidates.

~~~
groomed
You mentioned all three things that algo-strong dev will also do. Because
there is no correlation

------
Snoozus
They're really useful if you are looking for someone to do algorithm-heavy
work. Also to check if someone actually has the CS background they claim.

------
t-h-e-chief
Most people who are hired will have recently graduated, due to the exponential
growth of software developers. These interviews are really just an examination
question, like you would do in school. Companies use them because they can
easily show whether a person can retain and then apply knowledge of computer
science. And must companies do not know how to test candidates otherwise.

------
iM8t
Not all interviews are algo-heavy. I recently interviewed for a position in
AWS and the challenge was a simple floodfill argo (leetcode easy).

~~~
dillonmckay
Did you get an offer?

~~~
iM8t
Yes. :)

------
LandR
You realise that not everyone is a web developer?

------
majky538
Think twice before getting hired. Some companies are like nice looking
Instagram profile, but behind the scene it just sucks.

------
croh
Do you know Goodhart's law ? [https://coffeeandjunk.com/goodharts-campbells-
law/](https://coffeeandjunk.com/goodharts-campbells-law/) Software engineering
is craft and there are many metrices. But sadly people focus heavily on
algorithm/ds only.

------
zerr
1\. Ageism (prefer early 20s)

2\. Making switching jobs harder

~~~
amadeuspagel
Why exactly should a company make switching jobs to them harder, for the
benefit of their competitors?

~~~
groomed
When big companies agree, and all play the same game.- They can save money and
time.

------
SamReidHughes
There isn't anybody who can make good software architecture who isn't also
good at data structures / algorithms.

------
amadeuspagel
It might work as an intelligence test.

~~~
booleandilemma
You mean they’re trying to hire people stupid enough to work for them by
putting them through things like take home projects, group, and multi-round
interviews?

------
new_realist
Algorithmic interviews test for intelligence. Everyone prefers more
intelligent and capable developers.

