How to structure a trainee program?

Question

At my company we are thinking about starting a trainee program for software developers. We are thinking about attracting people with a CS degree, but little or no experience (or people with relevant experience but no degree).

I'm wondering what the trainee program should offer and how to structure it. We want the trainees to be real members of our development team, but use a higher level of supervision, peer review, pair programming etc. We should also provide some amount of lecturing/mentoring and provide some required reading.

I'm thinking the program should contain a plan for two years, but I'm not sure. Trainee programs are not common for software developers in my country.

So what elements would you include? How do you suggest we structure the mentoring? What principles and practices should we focus on, and how should we draw up the "curriculum"?

PS: Our current team consists of four highly skilled agile developers. We mostly do .NET and practice TDD.

Answer 1

I don't think trainee programs are common in many countries, but are such a really good idea if you have the company's commitment behind such an investment (an investment of the time of the other developers and internal resources, plus the investment in the people you're selecting to train up).

As to what to focus on, of course that depends on the company, but also what the end result should be -- do you want to make new developers or people who can operate at a junior level but serve in related capacities like QA or project management (a PM with a good knowledge of development methodology is valuable). If you want to make developers, then focusing on language, structure, best practices, methodologies would all be important -- and all things that could be learned by doing/being mentored with some formalized workshops and reviews sprinkled in. If you want to make something else, then the balance could be shifted appropriately.

Thinking about when I've done (or seen) informal training (bringing junior developers up to mid-level over time), the focus on peer review and pair programming is key -- and that doesn't have to be formalized training, just a commitment to integrate it into the daily workflow for all involved -- and that's not a small commitment. As for formalized instruction, you might consider a half- or whole-day workshop ahead of any new process implementation, so that everyone is on the same page. Any required reading could come before those workshops, and everyone could learn from the discussions.

Answer 2

Four experienced programmers can probably put an outline of everything you need to know, but they may miss some of the steps to learn it or may take knowing basic concepts for granted. You least experienced member may have a better recollection of her training.

Start with an intern and do a short run. Then reevaluate the program and put something together for a full-time recruit.

Although I think a mentor program with some structure is a good idea, don't lose focus on your recruitment and selection process. A quality candidate will learn a lot on their own in two years without direct instruction.

Edit: Good candidates are going to thrive in this environment. Our profession may need to consider having programs like this and stop expecting universities to do the full job.