I agree with the CVS from Samson, but then lately CVS is a must with me for virtually everything
Then just have them checkout a seperate branch altogether and if they screw up you can ignore the branch, anything good and you can merge the branch back into the main trunk.
As for testing them out, something simple that doesn't require indepth information and the entire code... for example writing a spell or two, that way you can see how they layout stuff and examine thier style of code. What the spell does and how it work is another matter. Other options would be to get them to psudeo-code up a system that was a bit bigger than your average system, and look at how the design it and stuff... being able to explain an idea well means you can prolly translate it into reasonably good code. Also if you understand the concept os psuedo-coding and WHY you need to you prolly understand at least some coding nicities.
Advertising always has brought in the masses of "Yeah my l33t c0ding skillz" bunch who know a smattering of C, but little about the advantages of structured design and documentation to be useful as part of a group. The coders I worked with though, I trained. They maintained my spells initally including porting spells to use an internal soft-coded interpreted language I wrote, this developed into maintaining larger and more complex commands eventually working in the core framework as I modified it and working in harmony with the system design and contributing to system design meetings/discussions
I may be looking for too much in a coder though here... several years of working with professional (or at least trained) coders may have spoilt me a little