Hacker News Reader

Comment by theshrike79 | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

I don't disagree with your statement at all.

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

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

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.

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.

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)

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

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

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.

Reply on news.ycombinator.com