Tips for Mentoring Junior Developers

I love working with less experienced people. They're curious, motivated, humble and eager to please/learn. But there's a problem: If you expect polish without putting in the reps, you’re not developing talent, you’re crushing it. Managing a more junior person is a delicate balance of "great job, you're improving!" and "this isn't it.". Here's some advice if you're in that situation. How to manage a Junior person 101: - Set your expectations to "they're learning, I'm teaching." - More instruction/briefing - More training/coworking - More iterations - See things early - Slower pace to “get there” - Give deadlines & level of effort expectations - Tell them in advance, you're going to correct, critique, and support them and they should expect it because you want them to grow and thrive. Here's a primer for how I align with them when giving a mission: 1. Delegation: are you watching me, am I watching you, or are we doing it together? Review early & often together, ask them to set up those syncs. 2. Impact: here’s the problem, here’s the behavior to change, here’s what I don’t want (bad outcomes to avoid), here's what number moves if it's done right. 3. Timing/effort: here's when I need to see something / when we need to have an impact. Don't spend more than {x} amount of time compared to the ROI. 4. Briefing: give examples of things to research (tools, competitors, product experiences, or out of the box examples). Ask them to think holistically about downstream impacts, scaling, user pain points, and other non-functionals (security, compliance, systems-thinking, integrations, partnerships, costs, revenues, monetization, roll-out, etc). 5. Debriefing: Ask them to come ready to explian flow/JTBD, differentiation & delight opportunities as well as risks. Set expectations for impact & strategic alignment points (when does the user feel/do something that we want, why is it an improvement over their status quo.) Give examples of the formats you want to see things in so they know what YOU need to know. When giving adjustment feedback: - You must prepare: ask to see before you talk about it so you can balance the negative and positive elements to convey. Don't burry them in critiques. - Tell them when it's not hitting the mark, but be specific about why. I like this: "We're not yet at the level we need, here's what we're going to do to get there together" -> note all the 'we' talk. YOUR job is to give the plan. THEIR job is to follow it. - Reassure them that it's going to take time to develop skills, and to be patient with their own pace. - Keep track of what is going right. Notice it. Say it often. You are their scaffolding, act like it!

I am a Sr. Software Engineer at Oracle with over 6 years of experience. Great seniors at Amazon and Microsoft have mentored me. I am now mentoring some really smart junior engineers. One thing I wish both sides of the table understood to make the process a bit easier would be this: Senior developers should act more like mentors and less like managers. Junior developers should act more like owners and less like task-takers. What does this look like in practice? For senior engineers: 1) Share context, not just tickets. Explain the tradeoffs and the reasons behind decisions. 2) Review their thinking approach, not just to approve or reject. Leave at least one learning point in every session. 3) Give space for juniors to think aloud. Help them debug their approach before you hand them your own. 4) Protect them from random chaos when you can. Take the heat upward, pass clarity downward. For junior engineers: 1) Do not show up to a senior with an empty page. Try something first, even if it is wrong. 2) Ask for feedback on your thinking, not only your code. 3) Own the problem from start to finish. Logs, tests, edge cases, rollout, follow-up. 4) Take notes and close the loop. If a senior explains something once, capture it so you can use it again. The best teams I have worked with did not feel like “senior vs junior.” They felt like a group of people at different experience levels, all caring about the same product. If you are a senior, you are already a role model, whether you want it or not. If you are a junior, you are already part of how the culture feels. Act like mentors. Act like owners. The product gets better this way, but the people get better too.

What I thought was a teachable moment for two software engineering interns turned into a wake-up call for me. I was explaining a complex optimization problem and wrapped up with, “And I’d fix it if I had more time.” One intern asked, “How? What does the solution look like?” I spent 30 minutes walking them through the solution, how I came up with it, and how I’d implement it. Two days later, the interns scheduled a code review with me. They’d put in a couple of 16-hour days and implemented the optimization. That version wasn’t pretty, but after a week and 3 iterations, they had a working implementation. I could have spent the same amount of time teaching them to implement the optimization or implementing it myself. 2 years later, the optimization was deprecated, but the interns had become exceptional software engineers. Make time to develop people on the team because that investment has a higher ROI than most other work you’ll do. Be patient with people who don’t work as fast or do everything right the first, second, and third time. It’s hard to stand back and watch, but that’s how people learn. Pair junior engineers, developers, and data scientists up to do the work with a senior++ mentor doing periodic reviews. Mentor people on real-world problems, even when the complexity exceeds their current capabilities. Teach them, but expect them to struggle with the problem independently before coming to you for help. At the senior++ and manager levels, we transition from software developers to people developers. Mentoring and teaching are capabilities that must be taught and developed, too. Invest in upskilling people making the transition, not just junior-level people.

A few years ago,, I had a junior engineer on my team who struggled so much during his first few months, he was about to be put on PIP and I was 80% sure he would lose his job. Mukesh was fresh out of college, full of energy, and genuinely excited to prove himself. But within just a few sprints, he started struggling. He wasn’t missing work or slacking off, he was putting in extra hours. But his pull requests were almost always late. The code was complex, over-engineered, and incredibly hard to debug. And by the time he’d arrive at a working solution, we were already behind on deadlines. He didn’t have a knowledge problem. He had a sequencing problem. Mukesh was trying to write the perfect, most performant solution from day one, jumping straight to “optimal” without first getting “correct.” So one day, I pulled him aside. I said: “Look, forget everything you know about perfection for a second. Try this instead: ‘Make it work. Make it right. Make it fast.” (this is from Kent Beck, btw, top tier advice) I broke it down for him like this: 1. Make it work – First, solve the problem. Doesn’t matter how messy the code is, just get it working end-to-end. Prove you understand the requirements. 2. Make it right – Now that it works, clean it up. Refactor for readability, structure, maintainability. Make it easy for others to understand. 3. Make it fast – If and only if performance is a blocker, then optimize. But never at the cost of clarity. Next sprint, Mukesh applied that exact approach. The result? On-time delivery. Readable code. Almost no comments in the code review. And for the first time, he ended a sprint feeling confident instead of defeated. It has been sometime, He’s now a senior engineer at Bytedance now, mentors new grads like he once was. I am quite happy at the pace he’s grown. You see, in engineering (and life), progress doesn’t require perfection from the start. Just the discipline to sequence your steps right. That’s what changes everything.

Mentoring junior and entry-level people has been one of the most rewarding parts of my career. Here are seven things I say to all of them: 1. 𝐏𝐚𝐭𝐢𝐞𝐧𝐜𝐞 𝐢𝐬 𝐤𝐞𝐲: People want immediate results but your career will last decades. Learn critical behaviors now for payoffs down the line. 2. 𝐇𝐨𝐰 𝐭𝐨 𝐚𝐬𝐤 𝐟𝐨𝐫 𝐡𝐞𝐥𝐩: When you get blocked try three different things before asking for help. This way you can talk about what didn’t work instead of just saying “help me I’m blocked.” 3. 𝐋𝐞𝐚𝐫𝐧 𝐭𝐨 𝐟𝐢𝐬𝐡: When someone does unblock you ask enough questions so that you don’t have to go back to them for similar issues. 4. 𝐔𝐧𝐝𝐞𝐫𝐬𝐭𝐚𝐧𝐝 𝐄𝐱𝐩𝐞𝐜𝐭𝐚𝐭𝐢𝐨𝐧𝐬: You may assume that you’re doing really well but aren’t, or you assume think that you’re struggling when you’re picking up on things quickly. Ask your manager about what is expected of you in an explicit way to avoid surprises. 5. 𝐍𝐨𝐛𝐨𝐝𝐲 𝐫𝐞𝐚𝐥𝐥𝐲 𝐤𝐧𝐨𝐰𝐬 𝐰𝐡𝐚𝐭’𝐬 𝐠𝐨𝐢𝐧𝐠 𝐨𝐧: Juniors typically think that everybody else understands everything. They don’t, they are just more comfortable with the fact that they don’t know everything. 6. 𝐁𝐞 𝐨𝐛𝐬𝐞𝐫𝐯𝐚𝐧𝐭: Because juniors are typically hyper-focused on becoming competent, they will focus on other’s knowledge rather than the way they operate. It’s much more educational to see how other people go about their work than trying to memorize a bunch of facts. 7. 𝐓𝐡𝐞 𝐠𝐨𝐚𝐥: You are no longer a junior when you can operate independently. It’s typically not about what you know. It’s about whether you know where you fit in to a broader organization. What was the best piece of advice that you received as a junior?

Ever noticed how certain embedded teams transform junior engineers from "LED blinkers" to production-ready developers in record time? 🚀 The secret isn't fancy tools or complex processes—it's intentional mentorship. The most effective embedded mentorship goes far beyond casual code reviews: • Structured one-on-ones focused on both technical and career growth • Carefully designed project experiences that stretch skills without breaking confidence • Deliberate sharing of "war stories" that contextualize technical decisions • Creating safe spaces for asking the uncomfortable "why" questions about system architecture When done right, the ripple effects are remarkable: - Junior engineers contribute meaningfully to production code 3-4x faster - Documentation quality improves as knowledge transfer becomes cultural - Teams build resilience against the "bus factor" problem - The entire organization develops a foundation of technical trust I've seen teams where this mentorship culture turns into their strongest recruiting advantage. Engineers actively seek out these environments over higher-paying alternatives. What specific mentorship practices have you found most effective in embedded teams? Have you been on either side of a mentorship relationship that fundamentally changed your career trajectory? #EmbeddedSystems #EngineeringLeadership #Mentorship #CareerGrowth #EmbeddedSoftware

"Be the senior you needed when you were a junior." Too often, mentorship focuses on process, outputs, or “getting results.” But what truly shapes careers is the human side of guidance: People leave when they feel invisible. Their questions go unanswered. Their ideas never get a platform. Their potential stays untapped. Their confidence quietly fades. If you want to nurture the next generation of talent:  • Listen first, advise second  • Share knowledge generously  • Create opportunities to lead and experiment  • Recognize effort, not just outcomes  • Encourage curiosity and risk-taking  • Give honest, constructive feedback  • Make room for growth before expecting perfection  • Celebrate progress along the way  • Protect focus from constant noise  • Include them in the “why,” not just the “how” These aren’t perks. They’re practices. It takes presence, consistency, and the courage to lead differently. ---------- Follow me Gav Blaxberg for more content like this. ♻ 𝐋𝐢𝐤𝐞, 𝐂𝐨𝐦𝐦𝐞𝐧𝐭, 𝐑𝐞𝐩𝐨𝐬𝐭 to share with your network ♻

If I were mentoring a junior dev today, I’d drill in three habits: 1) Learn your tools. Know your shortcuts. Learn how to type fast. Master your OS. The devs who move the fastest aren’t always the most clever - they know their environment cold. 2) Never stop learning outside of work. Your job won’t teach you everything (especially now). Most of the real breakthroughs come from side projects, curiosity, and self-driven exploration. 3) Communicate clearly Don’t hide bad news. Don’t protect your ego. Just be direct. The highest paid developers aren’t just good at coding - they’re very good at collaborating. Want a shortcut that helps you do all three? Go to hackathons. You will learn tools under pressure. Pick up new frameworks fast. And get plenty of reps working on small teams with tight deadlines. There’s no better training ground.