Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 104 posts

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

#71

Post by eanthy »

theshrike79 wrote: post #23
seanwilson wrote: post #16

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

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

100% agree. In all my years of coding and other people I know you literally never need to implement an algorithm yourself or do anything that is already provided by a library/framework. Knowing alrogithms/data structures is only ever useful for interviews and nothing else. On daily basis you just make classes and basic CRUD operations and mostly design rather than any hardcore logic let alone algorithm... Interviews are unrealistic.

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

#72

Post by seanwilson »

Aaargh20318 wrote: post #63
seanwilson wrote: post #16

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

> You need a high-level understanding of these concepts, sure, but don't get bogged down in details when they don't matter.

I think we agree then. I don't think understanding sorting algorithm is super important (usually you don't do much in terms of configuring or choosing these when coding), but people should have a high-level understanding of the differences between e.g. dictionary data structures as you need to know which trade-offs to pick when using these as part of a library.

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

#73

Post by croh »

seanwilson wrote: post #54
theshrike79 wrote: post #23

Earlier quoted context omitted.

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

> 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. Genuine question: How would you describe the performance properties of an algorithm in API docs without talking about e.g. logarithmic, linear or exponential growth? How could you understand these concepts of growth without knowing some basic algo…

I can understand intent of your question. But as per my experience, very few fresh devs read manuals. They try to search something like 'how to sort in python/php/java blah blah'. Now this may or may not an ideal way but it works. Not all have to deal with scale like google. (getting 1000 customers is big deal itself).

Now if you're really smart mechanic and brave enough to face interesting challenges, you start building solutions with intution. After sometime, you slowly realize & accept gap between your knowledge and PhD. So you keep learning and improving yourself on the fly. I am not undermining importance of algorithm knowledge but many businesses need just working solution. They deal with scale when business scales. Just trying to answer your genuine question. Performance comes in consideration if only business demands.

Also on side note, asking engine designer to make hands dirty and fit screw (in given time - without manual) is not always good skill-test if HIS JOB NOT REQUIRES IT. This thing is easy for mechanic as he is doing it daily. Designer will somehow make it work but obviously she will take more time than mechanic. Now there are always exceptions but hope you get the gist.

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

#74

Post by EnderMB »

mav3rick wrote: post #21
EnderMB wrote: post #18

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 techniq…

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 fo…

I never said it was a problem. I have a CS degree so it doesn't hugely bother me. IMO, it's a necessary hurdle to ensure that you aren't swamped by thousands of candidates at every location.

With that being said, I would consider knowledge of DSA and the knowledge required for a FAANG level interview to be subtly different. There's a big difference in knowing how to implement basic data structures, sorting algorithms, and implementing BFS/DFS on a graph, and being able to dissect a LeetCode style coding problem and implement a solution that's good enough for a FAANG-tier company.

As far as people being one-trick ponies, I would disagree. They've simply specialised in a different aspect of software engineering, and just like how a Google engineer can learn to build a dynamic API wrapper with Ruby meta-programming and Rails, a Ruby engineer can learn dynamic programming and Dijkstra's algorithm.

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

#75

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

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

#76

Post by walterstucco666 »

mav3rick wrote: post #58
walterstucco666 wrote: post #42

Earlier quoted context omitted.

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.

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 .

That's very different from "algorithm-heavy interview" process.

You could just ask "do you know when quicksort becomes quadratic?"

> Just use a "Library".

Not just a library, a battle tested one.

A bad implementation of quicksort can be much worse than "accidentally quadratic" bad.

a good library could shuffle the array before sorting it and never be quadratic.

Or has hints about quadratic behaviour in the documentation.

A good library could automatically choose the best sort algorithm for the input.

For example Java used quicksort for primitive types and mergesort for arrays of objects.

now it uses trimsort for both.

But the developer just calls `sort` on the collection.

> How about you know your stuff .

I bet you never encountered quadratic quicksort in your life.

   The probability that quicksort will use a quadratic number of compares when sorting a large array on your computer is much less than the probability that your computer will be struck by lightning!
How about you know your stuff.

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

#79

Post by abj »

caspper69 wrote: post #41
theshrike79 wrote: post #23

Earlier quoted context omitted.

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

No, it's not. You do not need to learn how to analyze algorithmic complexity from a theoretical point of view, which would be very math-heavy. But a college/university-level mathematics / comp-sci course in algorithms & data structures, usually only a 3 credit, 200-level course, isn't really asking too much. Then you'd know why your O(n^2) algorithm sucks on any dataset larger than a toy without having to be scolded.…

Then it would be fine if all these interviews asked was, "Why does this code with a O(n^2) algorithm suck?" People seem to have more of an issue when the interviews seem to blow right past that into leetcode hards.

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

#80

Post by Protostome »

theshrike79 wrote: post #23
seanwilson wrote: post #16

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

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

As a programmer, I want my user to have the best experience possible using my software. Using a generic sort function may be the optimal solution for me, as a programmer for getting the job done quickly, but in some occasions, it delivers an experience which is far from optimal for my user.

Let's take the sort function as an example.

There are many problems for which the sort function far from the optimal solution. For example, sorting billion numbers, each in [1,10000]. (You could do it in O(n), instead of O(nlogn), for large data sets it is significant)

Post reply on HN