Many people won’t like this idea, but I am advocating this wherever I can: regardless of the programming language and environment, if they don’t have any experience and if there are maintenance tasks which come up from real world bug reports of customers of yours, try to make sure they get assigned to that kind of task at least for 30-40% (+) of their time. “Here’s the bug report, have a look at it, solve it. If you don’t know what it’s all about, communicate with experienced colleagues, google it, whatever”. Real work on real problems, no toys, at least: not only toys. Make sure, too, that someone with lots of experience has a look at what they were doing before it gets released and shipped to the customer, of course. Make sure the new colleague gets honest feedback on what he did from colleagues and customers. Choose these tasks carefully in order to not overburden them, but keep in mind that some day you want them to do their work independently.

Doing bug fixing is learning on the job which lets them work on code which get’s actually executed and has some relevance (otherwise there would be no bug reports) and will show them in many examples how to not do it.

The focus is automatically put on pain points. They’ll start learning those details which are actually causing trouble. It also puts real responsibility onto their shoulders right from the beginning, which (while maintenance as such is not really attractive) can be rather motivating if they get it done to the satisfaction of the customer/end user. Going through what they did will be taken more seriously by your seniors cause they know the impact if things go wrong, and that way it will also simplify integration into the team, cause it will make them talk to each other automatically, as well.

The point is not to set them productive from the first moment (as it might look like). The point is to make sure that they know they are supposed to do something valuable right from the first moment, and to put a focus on what matters most without the need to actually create a list.

I do have some years of experience working every now and then with people coming directly from college into their new developer job, and the worst results I got to see was usually when someone without at least some experience in maintenance was asked to do new application development. Just make sure they always have someone they can ask for support if they feel lost.

Let’s assume first of all that you’ve hired junior programmers that are actually competent. This is not necessarily a safe assumption, especially since senior programmers interviewing “someone less experienced than me” is likely to overlook basic incompetence.

But, assuming they’re competent, the first step is to send them to a class. A one-week class will cost you $2,000-$3,000 (US). However, it will give them hands-on experience, with an instructor who (hopefully) understands the material, and a lesson plan designed to bring them up to speed. Sending someone off with a book and the directive to “learn this” isn’t going to be anywhere near as valuable, and is likely to cost more (the cost of the class is about equal to one wasted programmer-week).

After they have the baseline knowledge, work with them. Sit at an adjacent desk, and give up at least half of your time to making sure that they understand your business, and your way of doing things. Yes, it will decrease your productivity, at least initially, but in the long term in makes your team as a whole more productive. And if you think, again, about costs, if a junior person wastes a month doing the wrong thing, that’s probably about equal to a half month of your salary.

The toy applications you’re asking them to do should implement some basic CRUD functionality, and each developer should write their own code. But you can discuss the application in code reviews, and offer tips. They will need to understand the overall architecture of an MVC application first, if any reasonable expectation of productivity is possible.

From there, each developer should be able to strike out on their own into the associated subjects like Javascript, CSS, DAL’s, template generators, routing and so forth. You can give them guidance on which topics to study (it can be based on your company’s most pressing needs), mentor them, and monitor their progress. Move developers one at a time to simple projects that produce functionality that will move your actual development effort forward, the moment they demonstrate a grasp of the necessary skills.

You can pair some of your experienced developers with an apprentice as a sort of mentoring program. There should be guidelines available for the junior developers so that they know when they can interrupt their mentor, and for how long. Their mentor can supervise their work when they start writing real code.

You will have a better time of it if you can find young people who are very smart, intellectually curious, and self-starters. I’ve seen this process work; it was my prior employer’s approach, since he didn’t want to pay the big bucks for experts, although it was more of a “sink or swim” kind of thing (there was no formal training program as such). His biggest challenge was getting them to stay long enough to recoup his investment; there was always the lure of better pay somewhere else.