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

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.

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

There is a huge difference between knowing the fundamentals and having detailed knowledge about things you hardly use at the ready. For example, how often do you need to implement a sorting algorithm ? How often do you even have to make an informed decision on which one to use ? The one time you do, you can just look up the different options and their trade-offs. All you need to know is that these trade-offs exist, so you know that you have to look them up that one time when it matters.

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

So have I, but that's the complete other end of the spectrum. You need a high-level understanding of these concepts, sure, but don't get bogged down in details when they don't matter.

Knowledge of these subjects also doesn't mean someone is a good programmer. I've worked with people who had very in-depth theoretical knowledge, but who I wouldn't let within 10 feet of any production code. Usually people with an academic background. They would write a beautifully optimised piece of code but forget to do any input checking, error handling, etc. They were more concerned with their pretty algorithm than with writing robust, production-ready code.

Also, writing the most efficient code isn't always desired. Code also has to be robust, readable and easy to maintain. In a lot of cases a slight performance improvements come at the cost of readability and maintainability.

> 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

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.

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.