How can I teach and onboard other engineers faster?

• The core idea here is to make as much as your effort to be multiplicative as possible. This means that you do something 1 time, and then it has benefits over and over again. In this case, your goal is that when you share common knowledge, you do it in a way where after that initial time spent, it helps many people without you spending much additional effort.
• This makes office hours a good idea! I set up Instagram Android Ads office hours when a bunch of new Android engineers happened to join the team at once, and it was pretty helpful. Some thoughts here:
  • Make sure that the contents of the office hours are written down and shared afterwards. You can designate someone as the "scribe" since you will be the one answering questions.
  • Ask people to add questions to your office hours document beforehand to save time.
  • I don't think office hours are meant to be permanent. After everyone gets more comfortable, attendance will likely drop (or the meetings will get awkwardly silent). It's important to axe the meeting when that happens - That was the case for me.
• My rule of thumb: If I answer the same question 3 times, I'll write it down somewhere. This can either be some FAQ document somewhere, a more structured wiki, etc. If you find common themes with what people need help with, figure out how you can create a more permanent resource there, especially if you don't need to spend much time maintaining it.
• Empower others to help! In order to provide value to someone, you only need to be slightly less clueless than them. So after you onboard an SDE 1, empower them to onboard the other ones. It's a good way for them to build scope as well!

Related resources:

• [Case Study] Mentoring Junior SWEs [E3] to Senior [E5] In Just 2.5 Years At Meta
• "How do you answer questions effectively?"
• "How can I be an effective teacher when it comes to teaching coding concepts or mentoring within the company?"

Hearing office hours for team members felt weird when I read it. However, reading Alex's comment, I think that is a very good way to look at it.

I would however start by having recorded knowledge transfer sessions, upload them to the team's channel for future members, and taking Q/A at the end of each, this way you do it 1 time, and the rest of support can be an ad-hoc one.

Everything should be written in wiki, or readme files, I suggest you do all the onboarding tasks once at least to make sure they are clear, instructions are correct, and no hidden issues are there, this will reduce the back and forth, and save you a lot of time. (If this is done in the video sessions, that would be better).