It is not about technology or programming language, but some of the words that a person with > 7 years experience uses can throw off a new programmer. And people ask less questions when working remotely.
Anyone has a solution for this?
Personally I can't work from home because I need to make a strict separation to keep my sanity and I'm also the father of a 3-year old boy whom I can't disappoint every time he asks me to play with him.
Working remotely doesn't mean working from home. It depends on your preferences, but if you've got several people working remotely at a company, at least one senior is going to be working from a place where he could invite others to join him (like his own office, or a coffee shop, or something).
So how we do it right now: if the junior is from my country, I invite him to work with me for 2-3 months, to bring him up to speed. After that he can do whatever he wants.
Take this with a grain of salt though, as we are a small company and I don't really have much experience on this.
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.
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.
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.
We were both using the old SubEthaEdit app that allowed two folk to simultaneously edit the same code. It's not something I've looked at recently so am not sure what the current equivalent of something like that would be.
Worked pretty well, but wasn't as effective as my experiences of pairing with juniors in meatspace (the loss of body language added a significant communication barrier).