Textbooks and courses teach provide tutorials to the STL and enable programmers to use the STL containers and algorithms. In practice, it turns out that there are several hurdles to surmount, before the STL fits into every-day programming smoothly and safely. 
Examples of known problem areas: 

• INVALIDATION OF ITERATORS. Iterators are pointer-like objects that refer to elements maintained in a STL container. Depending on the type of the container, any operations performed on the container might invalidate any iterators pointing to elements in the container. Ever too often, programmers overlook this side-effect and as a result, have to cope with errors that are hard to track down - pretty much like traditional pointer problems. 
• NON-MUTATING ITERATORS. The associative containers in the STL must not allow modification of the key values that determine the ordering of the underlying binary-tree-structure. Depending on the implementation this might be expressed in terms of all iterators being constant iterators, which imposes severe restrictions on the usability of the container, or the iterators are non-constant iterators, which allows inadvertant corruption of the tree-structure. How do we cope?
• SIDE-EFFECT-FREE FUNCTION OBJECTS. Use of function object types is a programming idiom central to the STL. The STL specification imposes restrictions on the functionality of function objects that can be used in conjunction with the STL: they must not have side effects and they must not modify the container element through a dereferenced iterator. What does it mean in pratice?
• EQUALITY VS. EQUIVALENCE. While most algorithms use an equality relation, typically operator==() , when they check for equal values, the associative containers use a deduced equivalence, typically deduced from operator<() . When does equality differ from equivalence, and what difference does it make?
• STREAM ITERATORS. Stream iterators are a powerful and convenient abstraction that permit treating input and output devices as sequences of elements of the same type. Yet they have interesting semantics in the sense that several iterators on the same stream are not independent of each other, the result of which can be surprising. Learn more about stream iterators.
• USABILITY OF AUTO POINTERS. The auto pointer abstraction in the STL is designed to solve problems regarding management of heap objects in presence of exceptions: it automatically deletes the heap object it owns in order to prevent memory leaks. However, use of the auto pointer in conjunction with the STL leads to surprising results.
• POLYMORPHIC STRATEGIES. Numerous algorithms and containers take strategy objects: a sort() algorithm can be provided with a comparator which it uses for comparison of container elements. If such strategy objects are implemented using the strategy pattern, run-time polymorphism is likely to be involved, which again leads to subtle problems with the STL.