Welcoming a junior developer
The publication of a series of blog articles (in french) written by Thibaud, one of our developers, to describe his career change from web marketer to web developer, has been a good opportunity to think about why we hired him 1 year ago.
Thibaud had just finished a three-month training in Montreal, Canada. Retrospectively, that was a successful decision and it seems interesting to explain it: why did we take this decision and how did we put it into action?
Why did we hire Thibaud?
First of all, why do you hire in general? Mainly to improve the velocity and skills of the team, through an increase of the team size or replacement of a leaving teammate. In our case, it was all about getting from a 3-people team to a 12-people team within a year, to support the strong product ambitions of Captain Contrat. So, we had to find 9 new teammates, assuming we lost no one.
Hiring ruby developers is hard: there are very few candidates and many job offers. All senior developers are already working and -most of the time- happy. The only developers available on the job market are those that have just finished their training. Opening your recruitment to junior developers is a good way to enlarge your funnel because you know you’ll have candidates.
On the other hand, we asked ourselves whether the performance of a beginner would be too low compared to a skilled and experienced developer: wouldn’t we decrease our productivity instead of increasing it, by welcoming a less autonomous teammate? The answer came pretty easily: when you’re trying to build a team over the course a year, you aren’t looking for immediate productivity. Recruiting a junior developer probably means losing a bit of efficiency in the short-term, but the investment will pay off in the long term. Nevertheless, we had to make sure we would stay productive enough in the short-term, which is why we decided to keep a minimum ratio of 2 experienced developers per beginner. This ratio has since then remained a necessary condition to keep a nice and efficient team to work with.
Additionally, even if a developer is a coding beginner, he or she might not be so on other aspects of the job. Every arrival in a team widens its horizons by bringing diversity, especially in case of a career change. Talking about Thibaud, we knew his past working experiences would make him more skilled than us on side tasks, such as recruitment or product vision.
Make his arrival a success
Welcoming a beginner is more time consuming than welcoming an experienced developer, but it usually raises the same issues: how to integrate a newcomer, help them develop them skills and make sure that they are happy?
First of all, and most importantly, you must clear some time to be receptive, especially during their first two weeks. Be attentive, supportive, and patient, while leaving some autonomy to let the beginner learn by themself and face difficulties that they can overcome, in addition to giving them space to ask for help sometimes.
Then, a junior employee needs to continue learning in order to understand all the complexities of a job that is new to them. They also need to discover and understand the codebase that they are facing. They need to be mentored and to be given time to learn. A well-prepared scorecard including missions and skills might help him know what is expected from them and prevent them from negatively compare themself to others.
When Thibaud arrived, we were careful to choose for each sprint simple tasks that would be within his reach. It is important, for a beginner, to start with easy tasks that are ready for them. This builds self-confidence through small personal and team victories and prevents impostor syndrome.
Lastly, feel free to give your newcomer responsibilities. Why not push to production with them as soon as the first week? Moreover, just as written above, a junior developer is not necessarily an overall-junior. Regarding Thibaud, we quickly relied on his soft skills to contribute to recruiting new teammates.
In any case, it is essential to communicate a lot to make sure that they are blooming: does their job and everyday life match what they were looking for ? Are they happy with it?
10-months review
Almost one year after his arrival, Thibaud perfectly fits in the team.
He has improved a lot on topics that he had already worked with like ruby and rails, learnt a lot on new tools like react and faced new responsibilities like maintaining applications on production and dealing with legacy code.
His velocity on development tasks is slowly but surely increasing over time, but above all, he has been involved in some projects for which his past experience made him the best person to help the team move forward: as an example, he is responsible for our relations with external partners and involved in our recruitment process.
Our productivity decreased a bit upon his arrival, but came back to normal pretty soon. We kept recruiting more or less experienced developers, sticking to our golden rule: two experienced developers, at least, for one junior.
We tend not to make any difference between a junior who’s been on the team for months and an experienced developer. We are sometimes brought back to reality, for example when we start working on a complex devops project. Except for these kinds of special cases, we have no reason to consider Thibaud different from anyone else on the team now.
The gamble paid off!
