With the myriad of tools, tips and tricks that can exist in a team, onboarding can be a fun challenge 
I used to store our onboarding documentation on our gitbook repository along with the user guides for our application. Before that, they were stored in just my brain though 
Where do you store your onboarding documentation?
Iām onboarding at the momentā¦there is so much stuff to trawl throughā¦whether itās in some central repository, training sites, HR resources, Benefits and so on. Itās a bit of a minefield, knowing where to get the right information.
Confluence and/or Google drive or similar. I prefer confluence over G drive. I have also seen some nice examples of documentation on Notion https://www.notion.so, but I donāt know how good it is for a company.
My criteria for selecting a source:
1 - Has plenty of tools/options for formatting and visualization.
2 - Excellent search capabilities.
3 - Can give structure to documents like table of contents, footnotes, attachments etc.
4 - Can easily allow me to organize documents.
5 - Is pretty to read.
6 - Supports code formatting.
7 - Allows users to give feedback easily easily & stores them neatly.
8 - Tracks changes like version control & can notify people when something is changed.
9 - Can play content (e.g videos, pdf etc.) without having to download and play.
Iāve got stuff all over the place! 
Only partly joking. Our test coommunity has a ātest handbookā built with MKDocs which contains lots of stuff. Onboarding info, links to other useful places, docs, process stuff, guides etc. It needs to be tidied, but its meant to be āthe placeā for test info.
We used to have a tonne of documentation stored in our Azure DevOps wiki. It was a good way to store things because it was searchable and always accessible.
Then we realised that it was rarely and poorly maintained and no one was really using it.
Recently I started to use mind maps for tips, useful heuristics, team composition and test environment set up that we store on our document management system. I donāt think we document anything elseā¦
We give any new starts a tour of the application we are currently testing and task them with learning it.
We give them a charter and ask them to spend a fixed amount of time surveying the app with the purpose of learning and to raise any bugs they encounter.
A follow-up task is to create a product coverage outline (a list of all testable elements that they can identify). This is essentially a formal model of what they think the application is and what it does.
After each task we also ask for a session report to encourage note taking and to get them familiar with high accountability exploratory testing.
We debrief them and use these meetings for coaching.