Ask HN: What is the point of algorithm-heavy interviews?

It might work as an intelligence test.

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.

> 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.

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.

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.