We have three applications, 2 web client and 1 backend. Initally, I am setting training now with a walk through our documentation at a high level but show them where to find more in-depth knowledge is located in docs, setup peprsonal environment, and do a simple task so that we can go through the whole process of developing, testing and deploying to production.
Give them a high level overview of architecture and best practices.
Let them work on very small features/bugs (update text, fix small issues, ...) s.t. they learn the process end-to-end without spending much time on code.
[^ everything until here could be done without human explanation if you have solid documentation and codelabs]
Give them small features to work on s.t. they can own part of the codebase.
Here are some notes containing tips on how to "get to know a codebase"[0] from the new hire perspective.
One thing that has helped was having modular code that was documented, and most behavior changeable by configuration, and functionality that could be added by adding a plugin without really changing the code. That made the time to first contribution extremely short. The configuration files contained comments and examples, the code was documented, there were tests, and exception messages told you exactly what has happened, how to troubleshoot, and what you can do, profiling code, simulator like code, etc. Most questions new hires asked were about the behavior of a dependency of the project using the actor model, or about hardware and protocols.
In order to get that, one of the things I used to do was write the documentation for how I wanted to use the code, then write the code to match the documentation, then ask a _non programmer_ to follow the documentation. As long as the non programmer succeeded writing code with the library, I knew programmers could. I would confirm, though.
How much of the behavior can be controlled by configuration files? It helped to have as much behavior dictated by a configuration file.
What is the quantum to develop a functionality. Similar functionalities can be abstracted and have a sort of "cookie-cutter" way to add them as plugins discovered and loaded by the application.
A new hire can then get to know the application by developing plugins, for which the complexity and scope is limited, and then expand the domain to bigger parts of the application.