It's enough to know the existence and properties (benefits, drawbacks, running time, memory use) and to be able to recognize when to use a specific algorithm or data structure. I have no use for a candidate that can implement every sort algorithm on a whiteboard. What I want is a candidate that can identify problems and identify the required algorithms.

So I want someone who says "this is analogous a dynamic convex hull problem" or "this can be solved greedily by branch and bound" etc.

That knowledge has to be learned it can't be Googled. Mergesort or an A* implementation is googleable once you know you need them (which was the important bit).

Let's look at it in a different way: I have a CS education, and have worked professionally since the 90s. In my resume there's things like: - A code generator that took as input sources - High performance RMI libraries for a phone company - A entire retail system, from POS, to warehousing, reporting and PCI-DSS compliant key exchange systems - Distributed systems that coordinate work between thousands of nodes - A machine learning project that was recently mention in HN. - Migrated most computing in a fortune 50 company to the cloud

There are far more storied careers than mine in HN, but this is not a career of someone that spent their days writing CRUD apps in visual basic: I worked on fun things. Some of that worked involved algorithms: many of them very complicated. However, since I left school, other than in interviews, I never had to touch a high percentage of the algorithms in that page. Let me go a section at a time:

- I have used graphs plenty of times, but I can't recall using any of those algorithms directly. Yes, not even BFS. - I had to do linked list-like operations when I was writing in C at the beginning of my career. Not a single time since. - Zero dynamic programming. Nada. - Not a single manual sort algorithm, not a single manual search algorithm. - There's been plenty of trees, but none of the operations covered there. They were either provided by the libraries underneath, or never came up. - Number theory? Nothing from that list. I have implemented HyperLogLog though. Just don't ask me to do it from memory. -Early in my career I had to deal with some bit manipulation. I've not had to touch it in years. -Not a single one of those string/array manipulation ops

So my answer to the grandparent is that you can have a long, fun, not CRUD app career doing fun things without having to implement those algorithms once, because they are done for you. The algorithms those jobs need in practice are often harder, but you don't have to have them memorized: Some you go look for papers that solve your problems, others you develop yourself (and be afraid of that one, as I have seen a mathematician come up with a 5 page proof for an algorithm that only did what we needed in a parallel universe where latency is zero)

What almost every professional programmer has to understand what an array, a list, a set, a tree and a map are, and to go check the performance problems of specific implementations if it matters at the time. Almost every other interesting thing I have done was only relevant a small percentage of the time, and I could look up.

Interviews ask the questions they do because they match what is taught in a small subset of CS classes. We could teach other algorithms in those: Some of the ones I had to use would fit in said classes, instead of the ones we have. They can be implemented in under an hour too. However, nobody asks for them in interviews, because the people that come up with interview questions haven't solved them before.

So my point is not that you can ignore data structures and algorithms: You'll use some no matter what. But there is no subset of algorithms harder than a loop that every programmer uses in a regular basis, or data structures that we manually implement. We just ask for things that come from those same CS classes because we have no idea of how to assess if someone is any good, and the algorithm classes were some of the harder ones in college, so we assume that if you have them memorized, you must be pretty good. And we assume wrong.

Im a frontend dev by day. Golang/rust by night where Im in the need of learning DS/Algo anyway.