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

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

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

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.

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.

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 (eg 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: /

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.

but someone who is old would have studied this repeatedly if they applied to multiple interviews of the same kind, so they would have internalized 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.

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 mainta ining “)

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

>Who really cares about algorithm on daily bases. I find that statement quite depressing to be honest. Why would you be so happy to deprive yourself of a huge source of 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.

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.

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.

>why do people make such a big deal about this ?

You’re arguing a point they didn’t make.

The point they made is that most coders don’t need to worry about algorithms on a daily basis, and that reflect poorly on them in interviews where they expect you to not-so-subtly fake your cleverness with “aha!” moments when you’re being drilled on the fine details of complex algorithms that you maybe once needed to implement in the past 20 years. (On the rare occasion that these coders need to worry about algorithmic scaling, they will re-use an implementation of their fine standard library or adapt one from another source, without turning it into a brain exercise of reasoning about and building the whole algorithm on scratch on whiteboard while a bunch of strangers are sitting there judging you and prompting you to explain your thought process as you go).

It’s nothing to do with whether you have the fundamentals of basic algorithms down or whether you can select an appropriate algorithm for a real world problem.

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.

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

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.

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?”).

>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

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.

Yes everyone is a web developer who would never need to learn about “algorithms”. Anything that works against this HN crowd is obviously a big plot against them. Never mind that most people can’t differentiate when a map is better over a list. Or why binary search is fast. Don’t know how or when to use a graph. These people are one trick ponies and never tend to grow out of their comfort zones. They don’t have the foundations to work on new and exciting projects. But obviously it’s the companies fault for wanting someone with strong fundamentals.

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.

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.

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.