[lkozma]

This is a valid criticism from a practitioner point of view. From someone doing research in algorithms and data structures or someone just curious about it at an intellectual level, there is a different criticism:

All this focus on algorithms for the sake of interview-preparation gives the false impression that the field is a closed body of work. In reality it is an active and lively field of research with many (even most) basic questions not yet understood.

Someone could go through these 500 questions and for (almost) all of them formulate variants/extensions that would be open research questions. So instead of memorizing them, ask for each: Is this the best possible solution? Can I prove it? What if I restrict what the algorithm can do? What if I give the algorithm extra powers? What if the data comes online? What if the input is noisy? What if I want to optimize space usage instead of time? Is there a trade-off between the two? Etc. etc.

And related to the parent question: does the problem model a real practical problem? Why not? Can the model be changed to be more realistic?

All that being said, at a first look, the list seems like a quite nice collection of techniques.

[b0rsuk]

Not to mention it suggests these problem exist in isolation. These are neat problems with neat-looking solutions, mostly curated for elegance. Some are useful for embedded programming (doing X or Y in place or under certain time complexity).

This is almost never what you encounter in practice. In practice, you tend to get handed someone's creaking code and asked to build upon it.

[danieltillett]

My post wasn’t intended to be a criticism - I was genuinely interested to know the answer.

I work on what are considered hard CS problems and I rarely find the difficult part is knowing some data structure or algorithm, but in finding a way of translating real world problems into something that makes sense in code.

[thisisit]

I am not sure of your study of problems but you have spoken like techno-functional user. Finding a good translation surely is a big part but then getting things correct is also required. Writing couple of joins to get the correct data is fine but getting the correct join or data type or structure is also required. The difference being running a code for couple of hours vs in couple of minutes.

[danieltillett]

I am not suggesting that the right data structure is not important, just that is not where the difficulty lies. I can solve problems that my far more CS knowledgable employees can't because I have a better understanding of the domain. My solutions are not always the most elegant, but they work (most of the time).

[thisisit]

My point is on the elegance of a solution. As you said your solution works but that can be attributed to your domain knowledge. But the affect of your solution might be understated. We have people who write direct queries after much discussion with us. While we can't directly point them out, the queries tend to run for hours affecting other people's work and then we have to rework the whole thing all over again.