Many consider algorithmic knowledge to be the holy grail of programming, but you easily spend 10x more time with basic structuring and restructuring code.
Don't confuse designing algorithms with problem solving; debugging, refactoring, even naming functions are all problems you're solving. Heck, I bet you're not even designing algorithms, you're simply implementing known algorithms (and modifying them to your needs).
I think it's too common to have "instant gratification" tutorials where you learn some trick or some library to make a particular technology do what you want (for example, some little javascript or css snippet so that when you move your mouse over some text, it disappears). That's not real programming. Sure, a lot of work has to be put into learning little tricks and new libraries and whatnot, but real programming is thinking about data structures in an abstract way and manipulating them.
Get them to write a todo list application with the ability to sort the items in the list. The interface isn't terribly important, so try to get them to care more about the data structures.
Also, I've found that implementing Conway's game of life is useful. The map can be stored in several different ways (e.g. simple matrix of cells, two-dimensional linked list of live cells, quadtree as in hashlife) and manipulating each of those structures would give them techniques that are useful in many situations.
Try that on a large or enterprise level project and watch your product fall apart. The effort you save by not testing will be wasted fixing bugs many times over.
Test driven development isn't necessarily the best/right way to test all the time but you have to have some form of testing unless you just don't care about working on the software for over a month
On the other hand, if the program (or any of is constituent subunits) is designed right from the beginning keeping in mind that it is fundamentally a transformation from a precondition to a postcondition, from a logical predicate to another, then not only does locating errors become much easier, also testing becomes superfluous.
But it takes education to accept this point of view.
Hope whoever gets stuck debugging whatever code you spit out agrees with you viewpoint after spending hours tracing :/
If you can't express yourself clearly to your peers and managers, you won't control your career. If you can't work well with people, you won't control your career. If you don't understand the business context of your work, you won't control your career.
Just try to get the concept, and know that there are certain patterns you can use for correctly structuring and architecting your code. E.g. factory pattern, dependency injection, observer, etc.
Later steps:
Algorithms: Skiena's The Algorithm Design Manual http://www.algorist.com/
Learning about syntax / theory: SICP http://mitpress.mit.edu/sicp/
The first will make sure you can do work, the second will make sure that you can explain your work to other people, and the third ensures that you'll be paid well for your work.