How to help to an underperforming newbie do a better job?
I have been the only developer and the de-facto "senior developer" on my company's flagship product for a while (a .NET WinForms app, but that is not related). Just recently, they brought in a "newbie" developer with a fresh computer science degree. No experience with source control, unit testing, software maintenance, etc. 

I recently assigned him a small chunk of work and made myself fully-available for assistance, only to find his output lacking in a big way, both in terms of speed and quality. I tried not to be too heavy-handed, so the only upfront guidance I gave him is a wiki article describing the task that I update (but he has not), several code samples on new technologies (such as IPC), and I decomposed the tasks into several FogBugz cases (to which he provided no original estimates, actual time, or commentary until I told him what I would put). He rarely asked questions and, when he did, he seemed to follow my suggestions as though they were requirements, often without understanding them and even when they were wrong.

So ... I fully sympathize with his situation where you don't know what to do and are afraid to ask questions. I know it is my responsibility to do a better job, but no one gave me any guidance so I have no experience with what a better job looks like. Luckily, he is on vacation for a week, so I have some time to think about how to improve the process. Here are some of the items that occur to me, but I am open to suggestions and criticism:

1. Ask what part of the last iteration was most difficult. Ask what part took much more time than he expected.
2. Do some pair programming. I already suggested this and he seemed open to the idea, but each time we started I tended to take over because he wasn't typing fast enough. Something I have to work on. 
3. Have a code review before checking the work in. (We did not this time because of his vacation.) The code review would highlight the following items.
4. Require comments on all public members. (None of his code is commented.)
5. Require him to remove all unused code. (A cursory review shows he did not.)
6. Require him to commit code to each FogBugz Case as he completes it and/or revise cases where they differ from what he discovers while coding.
7. Require him to enter original estimates into FogBugz and toggle the "working on" flag to keep him on task.

While the code review stuff is specific and technical, I am more concerned with his ability to be a self-starter and to ask-for/get guidance where he needs it. I don't think of the FogBugz requirements (6 and 7) as hard rules, but it seems like he needs to follow them to keep him on track.

Also, I know I need to improve my mentoring/training skills as much as he needs to improve his coding skills. Any suggestions on where to start when the "senior developer" has not participated in a formal code review or made it through a pair programming session without taking over?

My impulse is to update the stuff he already checked in, but I know I should save that for a code review. I wanted him to check the work in so I could begin coding the part that uses what he checks in. So should I use what he checked in even though I don't think it is satisfactory?
How to help to an underperforming newbie do a better job?
===

I have been the only developer and the de-facto "senior developer" on my company's flagship product for a while (a .NET WinForms app, but that is not related). Just recently, they brought in a "newbie" developer with a fresh computer science degree. No experience with source control, unit testing, software maintenance, etc. 

I recently assigned him a small chunk of work and made myself fully-available for assistance, only to find his output lacking in a big way, both in terms of speed and quality. I tried not to be too heavy-handed, so the only upfront guidance I gave him is a wiki article describing the task that I update (but he has not), several code samples on new technologies (such as IPC), and I decomposed the tasks into several FogBugz cases (to which he provided no original estimates, actual time, or commentary until I told him what I would put). He rarely asked questions and, when he did, he seemed to follow my suggestions as though they were requirements, often without understanding them and even when they were wrong.

So ... I fully sympathize with his situation where you don't know what to do and are afraid to ask questions. I know it is my responsibility to do a better job, but no one gave me any guidance so I have no experience with what a better job looks like. Luckily, he is on vacation for a week, so I have some time to think about how to improve the process. Here are some of the items that occur to me, but I am open to suggestions and criticism:

1. Ask what part of the last iteration was most difficult. Ask what part took much more time than he expected.
2. Do some pair programming. I already suggested this and he seemed open to the idea, but each time we started I tended to take over because he wasn't typing fast enough. Something I have to work on. 
3. Have a code review before checking the work in. (We did not this time because of his vacation.) The code review would highlight the following items.
4. Require comments on all public members. (None of his code is commented.)
5. Require him to remove all unused code. (A cursory review shows he did not.)
6. Require him to commit code to each FogBugz Case as he completes it and/or revise cases where they differ from what he discovers while coding.
7. Require him to enter original estimates into FogBugz and toggle the "working on" flag to keep him on task.

While the code review stuff is specific and technical, I am more concerned with his ability to be a self-starter and to ask-for/get guidance where he needs it. I don't think of the FogBugz requirements (6 and 7) as hard rules, but it seems like he needs to follow them to keep him on track.

Also, I know I need to improve my mentoring/training skills as much as he needs to improve his coding skills. Any suggestions on where to start when the "senior developer" has not participated in a formal code review or made it through a pair programming session without taking over?

My impulse is to update the stuff he already checked in, but I know I should save that for a code review. I wanted him to check the work in so I could begin coding the part that uses what he checks in. So should I use what he checked in even though I don't think it is satisfactory?