I can't speak for anyone else but I think the important thing is understanding the tradeoffs of different ways of accessing data. At it's simplest you have thi

I can't speak for anyone else but I think the important thing is understanding the tradeoffs of different ways of accessing data. At it's simplest you have things like checking for existence using linear scans of arrays. Anyone with experience sees that as a bad thing to do because they understand that it's inefficient for any sort of sizeable array. But those who don't understand algorithms or data structures won't even know there's an issue. And that's the simplest case really. When you have a list and you need to efficiently add and remove items from both ends - then you want some sort of double-ended queue. I know where to find the one in my std lib and I know when I need to use it - which it turns out is almost never - I thought I did the other day, then I found a simpler way, which was actually a bit disappointing :) Then, as you say, you have things like A* or R-trees. The more of these you have an handle on - even just to know they exist, the better position you'll be in when you need them. But I don't even think that's the most important part of knowing data structures and algorithms (and really, I'm sure none of that's news to you if you're implementing A* searching). For me it's more about understanding efficient patterns for data access. So much of the work I do is about efficiently pushing data around in different forms. Often having a core chunk of data and then a couple of different indexing structures to allow me to interrogate it depending on the info I need.