It’s really important to focus a team culture of supportiveness. Your experienced developers should be available to answer questions, to pair program on a project or to dig into a tricky bug, and knowledge should be shared freely.
Our team is always very available for questions. We talk a lot on Slack and ask questions in public channels so that everyone has an opportunity to answer and/or read the answers given.
When onboarding a new hire we always have one person assigned as their developer onboarding buddy, and that person knows that being available is their #1 priority and they should drop anything else to help out.
We find that a mixture of pair programming and solo development work is the best way for our juniors to learn and improve. By being the navigator in a pair they get to see how a more experienced developer drives; by being the driver they get to practice those skills themselves; and when they’re working independently they learn how to unblock themselves when they’re stuck.
Feedback on code should be given early, often, and kindly. Some of the best code review comments I’ve seen have been long detailed explanations of Ruby syntax or functional programming techniques that our junior developers have learned so much from.
Junior devs should get feedback on their ways of working and communicating as much as they do on their code itself. We use retrospectives and ad hoc feedback conversations to help juniors develop. I’m a huge fan of Lara Hogan’s Feedback Equation as a tool for giving useful feedback.