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

[caspper69]

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.

There's 10,000 shades of gray between not knowing shit other than sort() and having a PhD. Use some common sense.

[abj]

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.

[caspper69]

I don't disagree with your statement at all.

But I do disagree with the statement I was replying to.

[seanwilson]

> 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 algorithms that demonstrate them?

It's not like API docs can contain explanations like "be careful, this algorithm gets a little slower each time you add a new item and this other algorithm get super slower each time!".

> And even fewer need to be able to improve on said algorithms.

Nobody is talking about inventing a new sorting algorithm. I'm talking about being able to analyse the CPU + memory growth properties of a complete program you wrote yourself (which are algorithms...) and fixing bottlenecks by applying appropriate standard data structures and algorithms.

[croh]

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.

[dillonmckay]

No, that is a bit extreme.

I would rather use a mechanic that has an underlying understanding of how a ICE works, rather than a tech that just plugs in a device and swaps parts.

I don’t need the mechanic to know how to fabricate an engine from scratch, but does have an understanding of what is under the hood.

[Protostome]

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)

[jf22]

Ok sure, but you can simply google different algos, try them out, and use the one that works best?

[Protostome]

That what you would do if you knew such a solution exist, but cant recall the exact implementation. In most cases, people who have no background in CS theory wouldn't even know such a solution exists and will resort to the generic "one-size-fits-all" solution

[eanthy]

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.

[Aaargh20318]

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

[seanwilson]

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

[clarry]

> 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 reflects 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 from 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 from scratch on whiteboard while a bunch of strangers are sitting there judging 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.

[seanwilson]

> On the rare occasion that these coders need to worry about algorithmic scaling, they will re-use an implementation from 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.

I never said they should be able e.g. code the algorithm from scratch on a whiteboard.

I'm saying you should be able to explain the basic principles of e.g. an array, a linked list, a hash table and a binary tree, and where each would be appropriate to use.

If you don't know these basic principles, I find it very unlikely you would know how to select library components or adapt algorithms that scaled to modest datasets.

[clarry]

> I'm saying you should be able to explain the basic principles of e.g. an array, a linked list, a hash table and a binary tree, and where each would be appropriate to use.

I think most of us agree with that. But that's beside the point, because that's not the algorithm-heavy interview people are complaining about big time.

[seanwilson]

It depends what you're describing as algorithm heavy. Do you have any examples?

I've seen people arguing you shouldn't have to know how a linked list, hash table or binary tree work. I think every programmer should know these ones. I think having to describe how quicksort works is getting too much, but knowing e.g. some search tree and graph algorithms might be appropriate depending on your domain.