Why you should have a trainee program
There are 3 main ways to aquire the skills for a junior software engineering role:
- Getting a university degree in computer science, complemented by internships or work placements for practical experience.
- Doing an apprenticeship, i.e. joining a company straight out of highschool to be taught on the job for several years, while earning only a stipend. Often formalized and combined with additional schooling.
- Being self-taught. Some people teach themselves programming, and have a track record to prove it, to the level needed to get a full-time job as a software engineer.
Which means there a many people that fall through the cracks because they do not fit any of those categories:
- people who do not have the means or opportunity to go to college
- people who are looking to switch careers into tech, but are in a stage of life where they have dependents, so they cannot afford to do a low-paid internship
- people who are self-taught, but do not have peers, mentors or a support network to give them enough guidance to reach the level required for a ful-time position all by themselves.
- people who studied computer science with good success, but neglected to get practical experience. They have the foundation and the talent to be software engineers, but currently could barey write FizzBuzz.
So there are many candidates out there that would make good programmers, but are lacking an on-ramp.
Incidentally, a lot of those people come from non-traditional or underprivileged background, so helping them start a career in tech is not just the right thing to do, but also your chance to find talent that others might not even notice.
What is a trainee program?
We defined our trainee program as an intense, time-limited training program to get people with a little coding experience ready for a full-time software developer position.
The time limit is important – it sets a deadline (typically 1 year), leading to a sense of urgency. And it means the company can terminate the contract after that one year if it should not work out, allowing them to take a chance on marginal candidates (remember, the whole point here is to get people into tech who otherwise would not have gotten in.
Salary for a trainee is set at around 70% of a junior developer’s salary – high enough to make a living, and be better than most alternatives, but low enough that the company can affort to have the trainee spend the whole year with a focus not on bringing in revenues, but on learning and building skills.
There are no formal prerequisites for our training program – requiring credentials would go against the point of the trainee program. The only requirement is that you have written enough code to be sure that this is something you want to do, and you have some aptitude for it.
How to organize a trainee program
You need to draw up a roadmap of topics that every trainee will learn. We do not care about academics here, but practical skills, so our roadmap covers mostly the universal basics of software engineering: version control, unit testing, linux, web frontend, SQL and so on. After that, trainees progress to the more company-specific topics, in which newly hired junior developers would often also require training before starting to work, e.g. less than universal frameworks, tools or products that our company uses.
We also have them do 2 larger projects: the first project brings everything they learnt together, by creating a small application end-to-end, from concept, architecture and technology selection to implementing the backend and the frontend, to QA and documentation. The second project does the same, but this time they create a larger application by working in a team of 3-5 people. This group project is a critical step, since working in a team exposes them to a lot of things that simply did not appear when working alone, from the need to coordinate to avoid stepping on each others’ toes, to the possibility to draw on the expertise of others, to the experience of integrating components written by different people.
Next, create a timeline for the year of the traineeship. In our case this means roughly 6 months of bootcamp, going through the topics listed in the previous paragraph.Then 3 months onboarding to an existing project, similar to an internship, where trainees join the team off the critical path by getting involved with testing, documentation, small bugfixes etc.
And finally the last 3 months they join a real project in a normal junior developer role, doing the same work they will do after their trainee program when hiring on as a permanent employee. The goal of this last phase is to get a good signal if they have reached the goal of the trainee program – ideally, nobody on the team will notice when they end their trainee year and switch to being a permanent, junior developer.
Now you need to be able to teach all the topics on your tech roadmap. Which means you have to find mentors for every topic. Those mentors are normal developers that are willing and able to coach a trainee in e.g. Linux commandline basics. You should have a list of at least 3-4 mentors for each topic, because mentors need to be available full-time, and to take some time away from their main project, so not everybody who is willing will always be able to mentor. Work with the mentors to create a curriculum for the topic – that could be a wiki page listing books, articles or tutorials, references, a collection of exercises, or small training projects.
When a new trainee starts
Once you have your roadmap, timeline and mentors in place (and yes, that does take quite a bit of time), starting a new trainee is easy. You simply check with them what they already know, adjust the times per topic on the timeline, and name specific mentors per topic.
During the bootcamp phase, learning is mostly self-directed. The exact organization is up to the specific mentor and trainee. Most settle on something like a standup-like daily call or meeting to check on the progress, and maybe an end of day review of the exercises done during the day. Most important though is that the mentor is available during the day to answer questions and clear roadblocks.
As a manager, you use periodic 1:1s with the trainee to check on the progress vs. the defined timeline, help out with impediments, or take action if a mentor should not be available or otherwise not work out.
What we learnt from running the trainee program over several years
Some previous coding experience is needed.
Not to save time on the necessary training, but to see if they get over the hump of going from a few simple lines to larger, more complex projects, and to see if they still see themselves doing development all day after the initial excitement of trying something new has worn off. People switching from a different field without previous coding experience sometimes become great developers, and sometimes try it for a few weeks, and then decide that it’s not for them. We actually got some good recruiters and salespeople out of the trainee program, by taking on e.g. a salesperson who wanted to switch to develpment, and then decided not to go through with it – but that’s not the point of the development trainee program. So now we only hire trainees who have roughly one Udemy course worth of previous coding experience (no matter how they got it).
Motivation and ownership is the key.
In the beginning, we thought that it would matter how much previous experience a trainee had, or how close their previous career was to software development. That turned out to not matter at all. Much more important is for a trainee to be driven and self-organized enough to get something out of their training. When our first trainee joined, our preparation and organization of the trainee program was still pretty rough, so we had to improvise available mentors, collect training resources from scratch etc – but she made it, and relished the freedom to pick her own projects and sources.
Have a cohort of trainees.
Instead of one trainee at at time, have 1 trainee starting every 6 months, and get them together with 1-2 apprentices per year. This way, you not only get to leverage the effort you made in preparing the program over more people, but you will also have 5-6 people in various stages of learning at any time, ideally together in one office. Fresh trainees like having someone around who was just like them not so long ago, and has since made progress. Older apprentices learn best by teaching fresh starters (and also save you and the mentors time this way!). On a social level, being a trainee, with no real project, and therefor no project team, can be lonely – having other trainees around helps.
Have trainees interview trainees.
The best way to convince someone to start as a trainee with you is to have them interviewed by someone who was themselves a trainee not so long ago. Plus, former trainees are the best to answer questions and talk about their experiences in the trainee program.
Big investment up-front, amortized over time
Do not underestimate the effort needed to get started, set up the roadmaps and training resources etc. But once you have them in place, taking on one more trainee becomes ever easier.
Get Management buy-in
The fastest way to ruin a trainee program is the expectation that the trainees will do productive work as soon as possible. That only ensures that their training will be half-baked, and they will have trouble switching projects and building skills afterwards. It has to be clear to everyone involved that the trainee program is an initial investment. Likewise, the mentors need to take time away from their projects to effectively help their mentees – that needs to be communicated and agreed with their managers.
Unexpected benefits of our trainee program
We could pretty much always find more great trainees than we could take on. That is very different to any other position in software engineering. Since few companies are offering that kind of trainee program, it’s one of the few ways left in software to easily find great people.
Developers who joined initially via the trainee program turned out to be the most loyal employees. People remember that you gave them a chance at a time when they did not have many opportunities, and reward you by sticking around even when the going gets tough. Theoretically somebody could sign on for the one year of the trainee program, and then take a job somewhere else, meaning the time we invested in training them is lost – in practice, that never happened.
The trainee program turned out to be a great way to hire people from non-conventional backgrounds. People who do not know any software developers, or who do not have a role model in tech, often do not initially think that being a developer is something they could do, and only come to tech later in life, or obliquely, after going into a different field first. The trainee program gives them an on-ramp into tech, and gives your company a connection to good developers who you would have otherwise missed.
In the beginning, it was hard to convince people to become mentors. After all, it’s an additional responsibility besides their main project and team. But it soon became popular to be a mentor – experts love nothing more than to spread their expertise, and good people enjoy helping others grow. Soon being a mentor for a topic became seen as a badge of honor, as a recognition that someone is an expert in that topic. And it is a great way to grow people – becoming a mentor was often a first step to somebody becoming a team lead or staff engineer.
In a matrix organizaton, the members of one team might be spread across different projects. Which means they spend most of their time with their project team (even though they might change projects frequently), and feel little kinship with the other members of their organizational team. Mentoring relationships are a great way to create weak ties between the members of a team, turning a teammate from “some guy who reports to the same manager” into “this is the guy who taugh me SQL when I started”.
People will surprise you
It is amazing how quickly a smart, motivated person can learn when they have a good plan, good resources, access to mentors and can dedicate themselves full-time to learning and practicing. Most of our trainees would, after having finished their one year of training, code circles around fresh university graduates who spent 3-5 years in academia.