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