Comment by bjornjajayaja | Hacker News Reader

Comment by bjornjajayaja | Hacker News Reader

Parent Full thread

I tend to disagree with many of the sentiments. In particular, many software folks don’t know the most rudimentary data structures and algorithms. Those should be memorized, frankly. Lately I have been exploring old programming books on archive.org and realize how downhill the industry has gone from fundamental principles, which leads to “language-z” zealots to satisfy some business need.

The author mentions COBOL as being antiquated and irrelevant but in all honesty, modern languages don’t improve upon much. Underneath all the layers people add to modern languages (so the rest of the developer community can push buttons without even the faintest idea) lies assembly language and the machine.

Knowledge of the systems is abstracted away so much that people are focusing on mastering the wrong thing. One should be able to implement algorithms in C or COBOL or even assembly. Otherwise, it’s like learning to google the notes of a concerto without understanding the chords, scales, harmony, melody, etc.

I am having a lot of job interviews lately. Interviewers usually ask me about my latest experience. It was implementing a pretty clever parser involving a lot of memory management. So I give details about the algorithm to the interviewer. I try my best to make it simple to understand. But most of the time, I get this kind of comment: "That sounds great, but which kind of middleware/broker/framework did you use?" I answer: none, we crafted everything from scratch. And then come the "oh, no Angular then"? "Angular? What the fuck are you talking about?" And then I go into autistic mode: get lost, you buzzword seeker. So my piece of advice to everyone: algorithms don't get you hired.

I forget what I don't use. Should I rememorize those things every 6 months?

99% of the data structure decisions I make at work are whether I should use a vector, a tree, a hashmap, or (very rarely) a list. the standard library implementation of whatever I choose is almost always sufficient. I wouldn't expect the average programmer to be able to implement all of these on the spot, but if you don't use them enough to understand the basic trade-offs, I have to wonder wtf you are doing all day?

Even if you know the broad strokes, asking the average developer to implement most data structures will be a disaster. I'm reminded of the fact that most binary search algorithms are badly broken:

> When Jon Bentley assigned binary search as a problem in a course for professional programmers, he found that ninety percent failed to provide a correct solution after several hours of working on it, mainly because the incorrect implementations failed to run or returned a wrong answer in rare edge cases. A study published in 1988 shows that accurate code for it is only found in five out of twenty textbooks. Furthermore, Bentley's own implementation of binary search, published in his 1986 book Programming Pearls, contained an overflow error that remained undetected for over twenty years. The Java programming language library implementation of binary search had the same overflow bug for more than nine years.

Knuth had this to say:

> Although the basic idea of binary search is comparatively straightforward, the details can be surprisingly tricky

https://en.wikipedia.org/wiki/Binary_search_algorithm#Implem...

If the experts can't get it right, no developer in an interview setting has a chance. It's a game of "gotcha." The interviewer has some trick that they are privy to and are waiting for the interviewee to mess up and... GOTCHA! You got it wrong, it's this clever trick that you would have to know ahead of time! Silly person thinking they can get a job here without knowing the secret handshake.

I do APIs and Web Apps. I only learned the definitions for the data structures you mentioned for work interviews. Otherwise I wouldn't even know what they mean. But also above post mentioned memorising algorithms, so they seem to expect memorisation beyond knowing trade offs of the features your programming language provides.

They suggested one should have to know how to implement algorithms in Assembly to be useful.

Also the article author mentioned bubble sort as an example. Do you really need to know bubble sort by heart?

Every programming job is different. I worked for 6 years at a well known videogames company and never had to use a vector or a tree ever. I was mostly using lists and dictionaries and occasionally an array, and that’s about it. I never had to do anything more complex data structure wise than that and I never really had to write my own data structure nor anything approaching an algorithm.

that makes sense, but presumably you knew enough about vectors and trees to understand why you weren't using them?

I'm also one of those people who think people should know rudimentary data structures and algorithms, and the reason I think this is that they come up all the time!

Sure, you could get through the situations I'm thinking of without knowing anything about this, but if you don't think about it, you risk filling the code with lots of O(n^2) loops that could be O(n) if you added an extra map. This is how you end up with applications that are slow due to a thousand small cuts.

If you don't think about these things, then I can only assume that it's because you don't notice them when they come up.

To be clear, there's nothing wrong with choosing the slower implementation because its simpler. What's important is that you thought about the trade-off, and often the O(n) loop is not more complicated than the O(n^2) one.

It sounds like your position makes use of those data structures and algorithms - and the author's didn't. I think the key here is that you memorize the important aspects of your role while knowing how to get the answers for anything else.

Right. The author is otherwise memoizing ... via google.

Reply on news.ycombinator.com