How do we train our recruits to be full-stack developers
At Libeo, we train all our developers as full-stack developers. Since we are hiring a lot of new recruits, including unusual profiles like career transitioners or self-taught, bringing all these different profiles to be polyvalent developers can be difficult.
I have onboarded several developers, from young graduates to twenty years of experience, and, from the bunch of methods that exist, I’ll give you here the ones that helped me the most!
Attitude
All the techniques in the world will be useless if we (the trainers) don’t have the right attitude.
A good attitude allows the recruits to feel comfortable! Sometimes that will be natural, sometimes not… But at that point, we want to create a safe environment where a newcomer is never afraid to ask a question.
And the best way to do it is by asking questions ourselves. Not like the Socratic way where we ask questions that we already know the answer to. I’m talking about open questions that aim to understand our recruits. That’s why it’s not a method but must be a part of our attitude!
You can find tons of resources about questionology (yes there is a science about that), but to summarize it, I will give you an example:
- Did you feel stressed when you did this exercise?
❌ Oriented and close question where the answer is yes or no. That’s not making recruits think much about it. - How did you feel when you did wrong on your exercise?
❌ Oriented question that leads to a justification mindset. Will only make them think in one way. - How did you feel about the exercise?
✅ Open and not oriented questions that let them speak about what they want. We can then guide the discussion and dig deeper with some “why … ?”
If we have this attitude, communication will be easier. Even after the training. We will understand better what they know, what they understood, what part of the job will please them, and what part they will fear. Sounds good, doesn’t it? 🙂
So let’s start with methods!
Shadowing
The shadowing is kind of simple, at least on paper. We simply have to let the recruit follow us for our basic daily work. Not the hardest method, I agree!
But shadowing can be cold and distant, so how can we put the recruits in an observer position but still make sure they feel they can participate at any time?
Let’s start with the obvious: we have to explain what we are doing. It can seem easy but when an error happens it’s more natural to think silently and analyze the code than speak up and explain what we are thinking about. So, when we are navigating into the code, when we are staring at it, or even when we don’t understand something, if we want to make them learn, we have to explain why!
And also, the questioning. Everything will look very simple for us. It’s our code, it’s our job, we know how it works. But something that seems crystal clear to us will be totally unknown to them. So we have to understand what our recruits understand, even more, if they don’t ask questions. Do they know all of this? Or are they totally lost and dare not ask questions? 🤔
The more we understand our recruits, the more effortless the communication will be, and the more we can direct the training toward what really matters.
Finally, for shadowing, the best way to keep their interest is to make them practice. So let them write a line, two lines, or a function. And, step by step, they take the lead until going to the peer programming method!
Peer Programming
With this method, the new ones will really take the lead on the coding. The purpose here is to think and discuss about how to code together. They are many frameworks for this method, at Libeo we use these two:
- The 3min/3min: each developer has three minutes to code. We can put a timer and when it rings, the other developer takes the keyboard. For remote-friendly companies, there is a cool extension, Live Share, that allows us to share our visual studio code workspace.
- The supervised coding: only the trainees take the keyboard while the trainer guides them. Still, for remotes, we use the Slack huddle feature, which, in addition to the voice chat and shared screen, allows us to make ephemeral drawings on the other’s screen. Pretty practical sometimes!
The important point here is: the trainee has to practice!
It can seem obvious but, one of the frequent bad practices is to write all the code in the 3min of the trainer, and answer questions in the 3min of the trainee. This can lead to the trainees saying “Yes I understood” when they haven’t.
So use the framework that fits best, split the time as you wish, but in any case, the trainee has to code!
Also, it’s the best time to let them think on their own and make them gain confidence. So give them time to find their own solution then discuss both of your solutions. It’s way more motivating for the trainees when they are convinced about the solution than just applying it! And who knows? We can even learn something at some point 😉
And as always, ask questions!
Conclusion
We have other techniques like encouraging newcomers to review code, even more, senior’s code, and review together everything they don’t understand. We also, with a little more investment, created a dojo where they can practice on our architecture and methods.
But there are lots of ways to teach or to share the knowledge and we can use as many techniques or science as we want, teaching will always be a human thing. All good emotions will enforce memorizing and all bad will block it.
We should know what to teach but, the best way to teach it will come from the learner. That’s why questioning is so important!
