I've mentored junior programmers (e.g, some of my guys/coworkers are still in school studying Comp Sci despite my attempts to get them to drop out), and it doesn't have to be done in person. As long as there is good motivation and discipline and trust remote working can work perfectly well over Skype. Code reviews done through Skype will be incredibly resourceful.
However, if there is lack of trust or discipline, this will not work. But then again, if you are having this problem you should really reconsider whom you hire! I hire my guys as interns, and I can quickly figure out who I want and who I'll wish the best of luck after the internship is over (my internships are just really long interviews): the ones who can figure things out themselves, the ones who go through an issue tracker and look for new things to do, the ones who will constantly ask things on Skype. You can't mentor self-sufficiency!
Bottom line: the people you want to hire aren't going to be needing constant babysitting. Those people will do it themselves.
Everyone is much happier because people work where they want to work. We still have 1 day a week where we all meet up in person (granted, that's still optional, but everyone shows up for camaraderie, and I bribe them with lunch). I work from many places, on my own time--and so does everyone else. As long as their output is roughly meeting the mean productivity of everyone else, it will work.
Here's another thought: when you bring someone on board, get them to work on a fun project. For example, I have my guys build apps with Twilio that book tables at OpenTable automatically using mechanize. Some fun apps will get them to learn a framework and language very quickly.
When I was younger, I was mentored almost exclusively by the very knowledgeable people on Freenode IRC. It's not only possible, but it's much better to do this remotely.
I've found that when people receive criticism remotely, it tends to escalate into "I feel this way because I read this: <insert link here>". Then a debate proceeds about the merits of one approach or another. When people receive criticism IRL, it's much more common to be defensive, because the references are not immediately available and there's a desire to resolve the disparity immediately.
I google everything (at least, when I'm outside of the office), and if I have two minutes to google anything before responding, the quality of my discourse will always be higher.
I used to be in the office all the time. What ended up happening was that I ended up becoming a tutor and they weren't gaining the skills of an experienced programmer. The best thing you can do is force them to look up things. It's probably even a good idea that all questions go through Skype or email because you can answer them on your own schedule; meanwhile, you force them to work for the answers.
For example, I had to teach a fresh Comp Sci kid how to link to a C library several times. He had no idea how compilers or linkers worked aside from his school programming assignments. I taught him how to do this in VS and GCC Makefiles at least 3 times, and he still didn't learn it because he could turn around and ask me. I've learned you only force someone to learn when you don't provide them answers. You do yourself and that person a disservice by spoon feeding solutions.
However, if there is lack of trust or discipline, this will not work. But then again, if you are having this problem you should really reconsider whom you hire! I hire my guys as interns, and I can quickly figure out who I want and who I'll wish the best of luck after the internship is over (my internships are just really long interviews): the ones who can figure things out themselves, the ones who go through an issue tracker and look for new things to do, the ones who will constantly ask things on Skype. You can't mentor self-sufficiency!
Bottom line: the people you want to hire aren't going to be needing constant babysitting. Those people will do it themselves.
Everyone is much happier because people work where they want to work. We still have 1 day a week where we all meet up in person (granted, that's still optional, but everyone shows up for camaraderie, and I bribe them with lunch). I work from many places, on my own time--and so does everyone else. As long as their output is roughly meeting the mean productivity of everyone else, it will work.
Here's another thought: when you bring someone on board, get them to work on a fun project. For example, I have my guys build apps with Twilio that book tables at OpenTable automatically using mechanize. Some fun apps will get them to learn a framework and language very quickly.