(assuming mentoring them with the objective of becoming "engineers" rather than staying developers) Many code pairing/reviewing strategies assume that the ment

(assuming mentoring them with the objective of becoming "engineers" rather than staying developers) Many code pairing/reviewing strategies assume that the mentor is the one who has to teach everything on the job. Its not true, it slows everyone down and leads to "lots of talking" and less coding. Don't by shy of making them have a follow up learning checklist. When you are pairing or reviewing, leave them links that have helped you on the past, or give them concepts that they should learn in order to more effectively do the same task. The next day, ask them if they have had a chance. Not as a way of "control", its totally fine if they don't, and its also totally fine if they have "glanced through" theoretically. If they are eager to learn, they'll be asking you more questions back, and you can fill in the gaps (or point in more directions). Its as much an effort of the mentee as the mentor. Junior developers often just need "direction" because they don't know what they don't know. But they're quick to explore further only if pointed the way. Give them the resources they need to learn, not necessarily the learning itself and keep following up. Contrary to many opinions, juniors like having tough mentors (which is why mentor should not be a reporting figure). Communication and social skills are a large part of development. You should also be guiding them specific to the organization context, whom to reach for what, how to communicate better in different circumstances, how to reinforce basics (writing tests), make them present something they learned, help them build visibility by attending meetups, how to make decisions on technology, how everything has tradeoffs, how to negotiate their salary, how to talk product stuff with product (biz to biz, qa to qa, executive to executives), how to escalate from personal > IM > emails > calls > meetings, habits like task tracking and learning to estimate by slowly working on complexity points and matching up with their "self velocity", how to say no to more tasks and avoiding burnout, etc. The mentor only provides useful guidance, but in the end, the execution is up to the junior and the context of the problem they're working on. Ideally they should also not be having one mentor, but many with different styles and opinions.