When I got my first job as a software developer 6 years ago, the on-boarding I received consisted of wiki pages, diagrams, keynotes, and many meetings to walk through various architectures and system diagrams.
I thought there had to be a better way, but as a junior developer, I wasn't sure.
There is a better way.
Forget documentation, forget architecture overviews. Let your new developers actually code. Let them fail. Let them try to figure things out and ask questions. A lot of questions. Be there for them when they do have questions.
I often see new developers come in and someone tries to set up "XX system overview" meeting, which turns into an hour-long lecture where a seasoned developer shows diagrams and code examples. As the new devs start to look zombified and nod silently in agreement, it should not be hard to understand that such an approach simply doesn't work. Humans are terrible at absorbing information without a context, without experiencing the system themselves.
Most of us learn well in increments, by trying and failing, trying again, and getting it right.
Chances are, if you explain something to a new developer on a diagram, they will understand 20% of it, and retain 20% of that. It's not worth it.
Some might argue that letting developers go wild in the codebase might not provide them the necessary context or the "why" behind things - I would argue that it doesn't always help to know the context and the "why" when you're first trying to get to know a codebase.
I believe it is far more effective to let the developers tinker around. Once they are ready to learn the context, let them ask questions. That approach will save you time trying to explain something your mentee is likely to forget anyways. It will also empower the new developer to learn on their own time, explore the system in ways that works for them.