a few people have mentioned that you tend to not write sorting algorithms and data structures in this day and age. but it's still critical that they be understood so a developer can understand the trade-offs for selecting a particular library and also the requirements needed to interface effectively with the chosen algorithm.
C++'s STL library does a very good job about being somewhat "in your face" about time complexity. Java's collection api, which is also a well designed library, is much less in your face about time complexity and the various trade-offs.
Since I sling java code for a living, i'll whine about Java collections.
#1. I have solved performance problems with large datasets simply by re-implementing the hashcode method on objects. When explaining that a hashtable (or hashmap in java parlance) degrades to linear time if the hash distribution isn't sufficiently sparse, i'm reminded that these concepts are new to the folks implementing systems on which multibillion dollar businesses are run.
#2. explaining to folks why you have to override both hashcode and equals if you want to expect your stuff to work is equally as evasive as well as the following:
#3. pointing out that you should re-put a stored object into a hashtable after you mutate because the hashcode may no longer be accurate.
#4. explaining why when you iterate over a keyset for a hashmap things aren't in order, but when you use a treemap you are.
#5. choosing a linkedlist for queue-like operations, choosing a treemap for natural-ordering, choosing a hashmap for good average performance.
it would be nice if when these problems are encountered and unwound a lightbulb would go off and they said "oh! i remember this from CS-xxx class" but instead it's like.. "oh you're such a geek i bet you don't get laid much."
i think we get in trouble when we attempt to make hard things easy. most un-zen-like.