1) find a topic you care about
2) search for foss or just oss related projects
3) read both their codebase and documentation, learn exactly how they work
Writing in some sense, is a general form of programming.
Have them execute a project or effort in miniature.
If you have a "support tool" (how we generally categorize it, an internal product like a data analysis or transformation tool) that is needed but not urgently (depending on size and knowledge needed, a 2-8 week project with a real deadline at least 2-4 weeks past the deadline you give them), give it to them to develop. Have them go through all your process motions (set up the repo, get dev tools, set up testing, set up deployment if applicable, etc.). This integrates them into your overall organizational or team processes so that when they're working on the "real" product(s) they already know the process. This also lets you gain better insight into where they are as a developer and to mentor them (I let people run in circles for a bit with light prodding to correct bad designs before I step in, give them a chance to figure it out themselves before being heavy handed; set a time limit appropriate to your needs for this of course). This also is an opportunity for them to practice "requirements elicitation" from the users (likely other team members, if you run them through an internal-only project like I try to do).
Afterward (or if you don't have a project like that available) hand them one (and only one, correct focus and understanding of priorities is not yet a skill novices often have) task and mentor them through it. Again, focusing on the whole process. This ought to be a simple task, maybe even one that's already completed to avoid risk and have a measure of where it should go, just to exercise the real process. Once that's completed continue with less handholding but still one task at a time for a couple more tasks. After 2-3 tasks like this, which should not take very long this should take on the order of 2-4 weeks in most cases, start handing them bigger tasks from the queue and then let them operate like any other team member (whatever that means in your org).
And understand mentoring. New hires (especially new to the industry hires) need mentoring. It doesn't need to be you, but your organization should have people who can help. This is both career mentoring and technical mentoring (where I generally focus). On the technical side, there is a lot that new folks don't understand about task decomposition and time management, in particular, not to mention the actual technical work itself (how to use the language and tooling available, good design, design that fits the existing mold rather than fights it, etc.). Don't expect them to get it through osmosis. That may have worked for you, but it doesn't work for everyone. Tailor the mentoring to the individual. If they're a quick study, you may not need to do much more than check in for a couple minutes a day, for some you may have to be more proactive for a while.
In addition, I'd recommend:
Read and acknowledge the coding standards and best coding practices.
An efficient onboarding process on best coding practices would definitively save you time for your first code reviews with your team.
For example, at Promyze, we set up “Discovery Workshops,” some interactive coding challenges to discover/learn our best coding practices with concrete code snippets from the codebase.
The concept is simple:
- We built a list of best practices we want to introduce,
- We select for each practice some examples and counter-examples from the practice documentation,
- Then, each new team member will have to find in the source code where some best practices have been followed or not.
This really helps make onboarding and work more productive -- and fun.