The more you know about algorithms and data structures, the better you can do in technical interviews. That much is true. The same for things like recursion and dynamic programming.<p>In actual fact, nobody uses recursion in real life, and dynamic programming is of limited use outside of some very niche areas (unless you consider the generic concept of caching to be a type of dynamic programming). And, rarely do you need much in the way of data structures beyond lists, arrays, hash tables, and things that can be constructed out of them.<p>Most notably of the set of "things that can be constructed out of them," you want to know something about trees and graphs.<p>Anything beyond that is something that's going to apply only in certain very specialized situations. For example, if you're writing a crawler, knowing about Bloom filters comes in really handy.<p>Things that will actually come in handy are knowing various architectural patterns. This doesn't mean design patterns <i>per se</i> -- this would be things like service oriented architecture, for example. Most of these things you'll naturally gain through experience, but it can't hurt to read a book or two about them.<p>So, as far as actionable advice, I'd pursue at least the equivalent of a formal data structures class to strengthen your knowledge and give you the vocabulary to talk about things with other engineers. And, as I mentioned, background reading about things like architectural patterns won't hurt, either.<p>This is just my personal experience as a junior/mid level engineer. Your mileage may very well vary, and I hope some more senior people have other things to say.