This was years ago, so my recollection is a bit fuzzy on the details. But pair programming was mentioned, and they also thought about what kinds of tasks to assign and how to provide scaffolding.

So for instance, instead of giving a really broad assignment and then going through six rounds of code review because everything is wrong, sit down with them in the beginning and make an outline (while explaining the rationale) of classes, methods, and responsibilities. Then have them fill in the implementations. That way you can use code reviews to focus on a lot of the smaller issues that are more concrete and less hand-wavy, while giving them practice working within sane high level designs. As time goes on, move on to more abstract concepts and give them more design latitude until they're capable of making a module like that by themselves.

There was a bit about walking the fine line in how much direction to give -- too little and they're lost at sea and spending forever to merge changes, too much and you stunt their growth.

I think there was also a book recommendation, but I have completely forgotten what it was.

Anyhow, they said it all a lot better than this, and I really wish they had accepted our offer. :-P