LCN Docs

Appearance

Mentoring Engineers at Different Experience Levels ​

Table of Contents ​

Article

Interview Practice Questions

1. Core Principles: The Foundation of Effective Mentoring ​

Why This Skill Matters ​

As you transition from Principal Software Engineer to Technical Lead, your impact multiplies through others. At Aperia, CoverGo, and YOLA, you’ve managed teams of 10+ engineers. The difference between a good technical leader and a great one often comes down to how effectively they develop their people. A well-mentored engineer doesn’t just complete tasks—they grow in judgment, autonomy, and technical depth, eventually becoming multipliers themselves.

Mentoring is fundamentally different from managing or teaching:

  • Teaching transfers specific knowledge (“Here’s how OData expression trees work”)
  • Managing ensures work gets done (“We need this Azure migration completed by Q2”)
  • Mentoring develops the whole engineer—their thinking, problem-solving approach, career trajectory, and professional identity

The Fundamental Truth About Levels ​

Engineers at different levels aren’t just “less experienced” or “more experienced”—they have fundamentally different needs, learning modes, and growth obstacles:

Junior Engineers (0-3 years) need structure, patterns, and confidence. They’re building their mental models of how software works. Their biggest obstacle is often not knowing what they don’t know.

Mid-Level Engineers (3-7 years) need depth, autonomy, and exposure to complexity. They have solid fundamentals but need to develop judgment about when to apply which patterns. Their obstacle is often the gap between knowing techniques and knowing when to use them.

Senior Engineers (7-12 years) need breadth, influence skills, and strategic thinking. They’re technically strong but may struggle with ambiguity, cross-team coordination, or thinking beyond code. Their obstacle is often the transition from “solving problems” to “solving the right problems.”

Staff+ Engineers need vision, organizational leverage, and leadership presence. They must influence without authority and drive technical direction across teams. Their obstacle is often stepping back from the code to focus on multiplying their impact.

The Mentoring Mindset ​

Effective mentoring requires a fundamental shift in how you think about your role:

  1. Your job is to make them think, not to give them answers. When an engineer asks “Should I use a repository pattern here?” resist the urge to simply answer yes or no. Instead: “What are you trying to achieve? What are the trade-offs you’re considering?”
  2. Meet them where they are, not where you wish they were. You might see an elegant DDD solution, but if the engineer is still mastering basic service layer patterns, pushing advanced concepts will overwhelm them.
  3. Growth happens in the stretch zone, not the comfort zone or panic zone. Too easy and they stagnate. Too hard and they shut down. Your job is to calibrate the difficulty.
  4. Different people need different things from you. Some engineers need encouragement and confidence-building. Others need honest critique and higher standards. Reading what each person needs is a core mentoring skill.
  5. Long-term development beats short-term efficiency. Yes, you could solve that architecture problem in 20 minutes. But if you spend an hour guiding them through it, they’ll solve the next ten on their own.

2. Practical Frameworks: How to Mentor Effectively ​

Framework 1: The 70-20-10 Learning Model ​

Engineers develop through three channels:

  • 70% from challenging experiences (projects, problems, mistakes)
  • 20% from developmental relationships (mentoring, feedback, observation)
  • 10% from formal learning (courses, books, documentation)

Your role as a mentor primarily operates in that crucial 20%, but you also heavily influence the 70% by choosing what challenges to assign.

Application:

  • For juniors: Structure the 70% carefully. Give them well-defined tasks with clear success criteria. Use the 20% to help them reflect on what they’re learning.
  • For mid-level: Increase ambiguity in the 70%. Give them problems without prescribed solutions. Use the 20% to help them develop judgment.
  • For seniors: Focus the 70% on cross-team coordination and architectural decisions. Use the 20% to help them see patterns across domains and develop strategic thinking.

Framework 2: The Mentoring Conversation Arc ​

Every mentoring conversation—whether scheduled 1-on-1s or spontaneous hallway chats—benefits from structure:

1. Establish Context (10%)

  • “What are you working on?”
  • “What’s on your mind?”
  • “What’s challenging right now?”

2. Explore Deeply (40%) This is where most of the value happens. Ask questions that help them think:

  • “What have you tried so far?”
  • “What’s your hypothesis about why X is happening?”
  • “If you had to choose right now, what would you do?”
  • “What concerns you about that approach?”

3. Guide Without Solving (30%) Share frameworks, point to resources, offer perspective:

  • “When I faced something similar at Tricentis, I considered…”
  • “Have you looked at how the Claims service handles this?”
  • “One framework that might help is…”

4. Create Accountability (20%) End with clarity and next steps:

  • “So what are you going to try first?”
  • “When should we check in on this?”
  • “What would success look like?”

Framework 3: Level-Specific Mentoring Strategies ​

Mentoring Junior Engineers ​

Primary Focus: Building foundational skills and confidence

What they need from you:

  • Clear expectations and structure
  • Frequent, specific feedback
  • Patterns and best practices
  • Reassurance that confusion is normal

Your approach:

  • Pair programming sessions: Sit with them for 30-60 minutes weekly. Not to direct, but to narrate your thinking: “I’m checking the logs first because…” This builds their internal dialogue.
  • Code review as teaching: When reviewing their code, explain the “why” behind your suggestions. “We prefer dependency injection here because it makes testing easier and follows our architecture principles.”
  • Gradual complexity: Start with well-defined tickets. As they succeed, introduce small amounts of ambiguity.
  • Celebrate progress: Point out growth explicitly: “Three months ago you were asking me how to structure this. Now you’re proposing solid solutions.”

Example interaction from your context:

A junior engineer on your Aperia team is implementing a new endpoint in the port management system. They ask: “Should I validate the input in the controller or in a service?”

❌ Bad mentoring: “Always validate in the service layer. That’s our standard.”

✅ Good mentoring: “Good question. What are the trade-offs you see with each approach? … Right, controller validation fails fast and keeps invalid data out of the system. Service validation allows reuse if we call this from multiple places. In our architecture, we typically do basic format validation in controllers and business rule validation in services. Look at how the Claims service does it—it’s a good example. Try implementing it and we’ll review together.”

Mentoring Mid-Level Engineers ​

Primary Focus: Developing judgment and ownership

What they need from you:

  • Exposure to ambiguous problems
  • Guidance on trade-offs and decision-making
  • Opportunities to lead small initiatives
  • Honest feedback on their growing pains

Your approach:

  • Socratic questioning: Instead of answering their questions, help them develop their own framework for thinking. “What would you need to know to decide that?”
  • Architecture review participation: Bring them into architecture discussions. After meetings, debrief: “What did you notice about how we evaluated those options?”
  • Delegated ownership: Give them a small system or feature to own. Let them make decisions, with you as a sounding board.
  • Exposure to complexity: When you’re dealing with cross-team coordination (like your work with BAs and infra teams), include them in discussions and explain the non-technical aspects.

Example interaction:

A mid-level engineer asks: “The OData query is slow. Should I add caching or optimize the expression tree?”

❌ Bad mentoring: “We don’t cache in that layer. Optimize the expression tree.”

✅ Good mentoring: “Walk me through how you diagnosed the performance issue. … Okay, so the expression tree conversion is the bottleneck. What are the options you’re considering? … Right—caching, optimization, or changing the query approach. What are the trade-offs? … Exactly—caching adds complexity and staleness concerns. Optimization might have limited returns if the fundamental approach is wrong. Have you looked at whether OData is the right fit here, or could we use a different querying approach for this use case? I dealt with a similar OData expression tree issue at [previous project]. Let me share what we learned…”

Mentoring Senior Engineers ​

Primary Focus: Strategic thinking and organizational impact

What they need from you:

  • Bigger-picture context on business and architecture
  • Coaching on influence and communication
  • Opportunities to drive technical direction
  • Challenge to think beyond their domain

Your approach:

  • Strategy discussions: Share the “why” behind architectural decisions. “We chose microservices here not just for technical reasons, but because we need to scale the teams independently.”
  • Cross-domain exposure: When you’re coordinating with architects and other domain teams (like at CoverGo), bring them into those conversations.
  • Reverse mentoring: Ask for their input on complex problems. “You know the payment domain deeply. What’s your take on this integration approach?”
  • Leadership opportunities: Give them chances to lead technical initiatives, present to stakeholders, or mentor others.

Example interaction:

A senior engineer proposes migrating a service from Azure Functions to containers. They’ve thought through the technical details but seem focused purely on the engineering merits.

❌ Bad mentoring: “Sounds good, write up the proposal.”

✅ Good mentoring: “This is a solid technical analysis. Before we move forward, help me think through a few things: What’s the business case? How does this align with our platform goals? … Right, the cost and performance benefits are clear. What’s the migration risk? How would you sequence this with our other Q2 priorities? … Also, this kind of platform change affects multiple teams. How would you communicate this? Who needs to be brought along? … Here’s what I’ve learned about getting buy-in for infrastructure changes: you need three narratives—technical story for engineers, business case for leadership, and operational story for the teams who’ll maintain it. Let’s work on framing all three.”

Framework 4: The Delegation Ladder ​

Mentoring happens through progressively delegating responsibility. This ladder helps you calibrate:

Level 1: “Do exactly this” (Highly directive)

  • Example: “Implement the endpoint following this exact pattern [shares code example]”
  • Use for: Juniors learning fundamentals

Level 2: “Do this, but here are some options” (Guided choice)

  • Example: “We need to handle this validation. You could do it in the controller or service layer. Here’s when I’d use each…”
  • Use for: Juniors gaining confidence, mid-levels in new domains

Level 3: “Here’s the problem, you propose a solution” (Structured problem-solving)

  • Example: “The import process is timing out for large files. Investigate and propose approaches.”
  • Use for: Mid-levels developing judgment

Level 4: “Here’s the outcome, you decide how” (Ownership with guardrails)

  • Example: “We need the reporting service to handle 10x current volume. Here are the constraints [cost, timeline]. You own the solution.”
  • Use for: Senior engineers, mid-levels in their strength areas

Level 5: “You see the gap, you fill it” (Full ownership)

  • Example: “You own platform stability. I trust your judgment on what needs to happen.”
  • Use for: Staff+ engineers, very senior engineers

Move engineers up this ladder progressively. Jumping too many levels creates anxiety or failure. Staying too long at one level breeds frustration.

3. Common Mistakes: What to Avoid ​

Mistake 1: Teaching, Not Mentoring ​

What it looks like: An engineer asks about microservice communication patterns. You spend 30 minutes lecturing about event-driven architecture, message queues, and saga patterns.

Why it’s problematic: They leave with information but not understanding. They can’t apply it because they didn’t develop the thinking that led to these patterns.

Better approach: “What problem are you trying to solve? What happens if services can’t talk synchronously? Walk me through your thinking… Right, so you need reliability and loose coupling. What patterns have you seen that address this? … Let me point you to how we handle this in the Payment service. Study it, try implementing something similar, and let’s review your approach.”

Mistake 2: The “Mini-Me” Trap ​

What it looks like: You mentor everyone to solve problems the way you would. You push DDD on juniors who are still learning basic layering. You get frustrated when senior engineers don’t approach problems with your level of architectural thinking.

Why it’s problematic: Everyone develops differently. Your path—15+ years across fintech, healthcare, education—isn’t their path. Your strengths (distributed systems, cloud architecture) might not be their strengths.

Better approach: Understand their goals. Ask: “Where do you want to be in two years?” Some engineers want to go deep technically. Others want to move toward management. Some want to specialize in a domain. Mentor them toward their goals, not yours.

Mistake 3: Inconsistent Standards ​

What it looks like: You’re lenient with code quality from a struggling junior but harsh with a senior engineer. Or vice versa—you hold juniors to impossible standards while letting seniors slide.

Why it’s problematic: Standards should be consistent, but support should vary. Everyone should write testable, maintainable code. But a junior needs more help getting there.

Better approach: Same standards, different scaffolding. “This code needs tests” applies to everyone. For a junior: provide test examples, pair with them. For a senior: “Why weren’t tests included? What’s blocking you?”

Mistake 4: Solving Their Problems ​

What it looks like: An engineer is stuck on a bug. You dive into their code, find the issue, fix it, and explain what was wrong.

Why it’s problematic: You’ve robbed them of the learning. They know what was wrong but not how to find it. Next time they’ll just ask you again.

Better approach: “Walk me through how you’ve debugged this so far. … What tools have you used? … What’s your hypothesis? … What would you check next? … Okay, try that and let’s see what you find.” Let them struggle productively. Only intervene if they’re truly stuck, and even then, give hints, not solutions.

Mistake 5: Feedback That’s Too Generic ​

What it looks like: “Good job on the PR.” “This code needs improvement.” “You should communicate more.”

Why it’s problematic: Generic feedback doesn’t teach. They don’t know what specifically was good or what specifically to improve.

Better approach: “The way you structured this service with clear separation between API models and domain models—that makes it much easier to evolve independently. This is the pattern we want across services.” “This function has three different responsibilities. Let’s talk about single responsibility principle and how to refactor this.” “In yesterday’s standup, you said ‘I’m working on the thing’—be specific. Say ‘I’m implementing the claims validation service, blocked on the data model decision.’”

Mistake 6: Not Adapting to Learning Styles ​

What it looks like: You mentor everyone through verbal discussion because that’s how you learn best. Or you always send documentation links. Or you always do live coding sessions.

Why it’s problematic: People learn differently. Some need to see it (diagrams, code examples). Some need to hear it (discussions, verbal explanation). Some need to do it (hands-on, trial and error).

Better approach: Pay attention to what works for each person. Ask: “What helps you learn best?” Then adapt. For visual learners, diagram the architecture. For hands-on learners, give them a task and review together. For verbal processors, talk through the problem.

Mistake 7: Mentoring When You Should Be Managing ​

What it looks like: An engineer consistently misses deadlines. You have a mentoring conversation about time management. A senior engineer writes code that violates architecture standards. You try to coach them on better patterns.

Why it’s problematic: Some issues are performance issues, not development issues. Mentoring is developmental. Management is corrective.

Better approach: Know the difference. If it’s a pattern—repeated mistakes, ignoring feedback, performance issues—that’s a management conversation with clear expectations and consequences. “We’ve discussed this pattern three times. This is now a performance issue. Here’s what needs to change and by when.”

4. Real Scenarios: Good vs. Bad Examples ​

Scenario 1: Junior Engineer Stuck on Implementation ​

Context: A junior engineer on your Aperia team is implementing a new microservice for port scheduling. They’ve been stuck for two days on how to structure the service layers.

❌ Bad Mentoring:

Engineer: “I’m not sure how to organize this service. Should the controller call the repository directly?”

You: “No, definitely not. We use Clean Architecture here. You need a controller layer, an application service layer, a domain layer, and an infrastructure layer. The controller calls the application service, which orchestrates domain logic and calls repositories through interfaces. Here, I’ll show you.” [Opens editor and starts coding]

Why this fails:

  • You’ve done the thinking for them
  • They’ll copy the pattern without understanding it
  • Next time, they’ll be stuck again
  • You’ve missed the opportunity to build their problem-solving skills

✅ Good Mentoring:

Engineer: “I’m not sure how to organize this service. Should the controller call the repository directly?”

You: “Good question. Let’s think through this together. What are the responsibilities you see in this service?”

Engineer: “Well, I need to receive the API request, validate it, save to the database, and return a response.”

You: “Right. And what happens if those are all in the controller?”

Engineer: “Um… it would be hard to test? And if we needed to call this from somewhere else, we couldn’t?”

You: “Exactly. So how might you separate those concerns?”

Engineer: “Maybe… a service layer between the controller and the database?”

You: “That’s the right direction. We follow Clean Architecture on this project. Have you seen the Claims service structure?”

Engineer: “Not really, I’ve mostly been in the API layer.”

You: “Okay, here’s what I want you to do. Look at the Claims service—specifically how it’s organized into folders. Notice how the controller, service, domain, and infrastructure are separated. Then sketch out what that would look like for your scheduling service. We’ll review your sketch tomorrow. Questions?”

Why this works:

  • You’ve guided their thinking with questions
  • They’re doing the investigation and design work
  • They’ll understand the “why” behind the structure
  • You’ve given them a clear next step and accountability

Scenario 2: Mid-Level Engineer Making an Architectural Decision ​

Context: At CoverGo, a mid-level engineer is designing a new integration between the Payment service and an external payment gateway. They come to you with a proposed design.

❌ Bad Mentoring:

Engineer: “I’m planning to have the Payment service call the gateway synchronously and wait for the response.”

You: “That won’t work. What if the gateway is slow or down? You’ll block all payment processing. You need an asynchronous event-driven approach with a message queue and retry logic.”

Engineer: “Oh, okay. So I should use SQS?”

You: “Yes, use SQS. Publish an event when payment is initiated, have a worker consume it, call the gateway, and publish the result. I’ll send you a diagram of how we did this in the Claims integration.”

Why this fails:

  • You’ve made the decision for them
  • They haven’t developed judgment about when to use async vs. sync
  • They’re following your pattern without understanding the trade-offs
  • You’ve reinforced dependency on you for architectural decisions

✅ Good Mentoring:

Engineer: “I’m planning to have the Payment service call the gateway synchronously and wait for the response.”

You: “Walk me through your thinking. Why synchronous?”

Engineer: “It’s simpler. We get the result right away and can return it to the user.”

You: “True. And what are the downsides of that approach?”

Engineer: “Well… if the gateway is slow, our API is slow too.”

You: “Right. What else?”

Engineer: “If the gateway is down, we can’t process payments at all.”

You: “Exactly. So what are your options here?”

Engineer: “I guess we could make it asynchronous? But then the user doesn’t get immediate feedback.”

You: “That’s the trade-off. Let me ask you this: what’s more important for this use case—immediate confirmation or reliability?”

Engineer: “Probably reliability. If we can’t process payments, that’s a business blocker.”

You: “Agreed. So if you go async, how would you handle it?”

Engineer: “Maybe… publish an event to a queue, have a worker process it, and update the payment status?”

You: “That’s one approach. What have you seen in our codebase that does something similar?”

Engineer: “The Claims service does something like this, right?”

You: “Exactly. Study how Claims handles external system integration—there’s a pattern there you can follow. But there’s another consideration: what if the gateway call fails? How would you handle retries?”

Engineer: “I haven’t thought about that…”

You: “That’s an important part of integration design. Research retry strategies—exponential backoff, dead letter queues. We have a tech talk recording on this from last quarter. Watch it, then update your design with retry handling. Let’s review the updated design next week.”

Why this works:

  • You’ve helped them discover the issues through questioning
  • They’re learning decision-making frameworks, not just this specific answer
  • You’ve pointed them to resources and examples in the codebase
  • You’ve identified a knowledge gap (retry strategies) and given them a path to fill it

Scenario 3: Senior Engineer Struggling with Cross-Team Coordination ​

Context: At YOLA, a senior engineer is frustrated because their work is blocked by another team’s delayed API changes. They want to escalate to management.

❌ Bad Mentoring:

Engineer: “The platform team said the API changes would be ready two weeks ago. We’re completely blocked. Can you escalate this?”

You: “Yeah, I’ll talk to their manager. This is unacceptable.”

[You send a terse message to the platform team manager complaining about delays]

Why this fails:

  • You’ve solved the immediate problem but not developed their skills
  • They haven’t learned how to navigate cross-team dependencies
  • You’ve reinforced escalation as the first response
  • You’ve damaged the relationship with the platform team

✅ Good Mentoring:

Engineer: “The platform team said the API changes would be ready two weeks ago. We’re completely blocked. Can you escalate this?”

You: “I hear your frustration. Before we escalate, let’s think through this. Have you talked directly with the platform engineer working on this?”

Engineer: “No, I just saw their manager’s update that it’s delayed.”

You: “Okay. First step is always direct communication. Reach out to the engineer—not to complain, but to understand what’s blocking them and if there’s a way forward. Maybe the full API isn’t ready, but they could expose a partial version. Maybe there’s a workaround.”

Engineer: “What if they can’t commit to anything?”

You: “Then you escalate, but with data. ‘I talked to [engineer]. They’re blocked by X. Our delivery timeline is at risk—we need the API by [date] or we need to find an alternative.’ That’s much more effective than ‘they’re late.’ You’re giving leadership options, not just problems.”

Engineer: “What if there is no workaround?”

You: “Then ask yourself: are we really completely blocked, or are there other things we can parallelize? Can you mock the API and build against the contract? Can you work on other stories? Part of being senior is finding creative ways to maintain momentum even when dependencies slip.”

Engineer: “I guess I could mock it and continue with our work…”

You: “Right. Here’s what I want you to do: talk to the platform engineer, understand their blockers, explore a workaround or partial delivery. If that doesn’t work, mock the API and continue. We’ll sync in two days and decide if escalation is needed. This is a skill you’ll use constantly as you take on bigger initiatives—managing dependencies and maintaining progress despite blockers.”

Why this works:

  • You’ve taught a framework: communicate directly, escalate with data, find creative solutions
  • You’ve empowered them to solve it rather than solving it for them
  • You’ve connected it to their career growth (senior+ skills)
  • You’ve set up accountability and support

Scenario 4: Mixing Experience Levels on a Project ​

Context: On your Aperia team, you’re assigning work for a complex feature involving microservice communication, data consistency, and new API endpoints. The team includes one junior, two mid-level, and one senior engineer.

❌ Bad Delegation:

You: “Sarah [junior], you take the API endpoints. Mike [mid], you handle the service layer. Chen [mid], you do the data model. Priya [senior], you do the message queue integration.”

Why this fails:

  • You’ve assigned work purely by component, not by growth opportunity
  • The junior gets the easiest work with no learning
  • The senior engineer does the hardest work alone—no one else learns it
  • No one is stretched appropriately

✅ Good Delegation:

You: “Here’s how I’m thinking about this feature. Priya [senior], I want you to own the overall architecture and design the message queue integration. You’ll also mentor Sarah on the API work. Sarah [junior], you’ll implement the API endpoints, but Priya will pair with you on the message handling part—that’s going to stretch you.

Mike [mid], you’ll own the service layer, which includes some complex business logic. I want you to propose the approach before implementing. This is a good opportunity to practice making architectural decisions in your area.

Chen [mid], you’re doing the data model, but I also want you involved in the consistency strategy discussions. You haven’t done distributed transactions before, so you’ll learn from Priya’s experience there.

We’ll have a design review as a team in two days. Everyone should come with questions and ideas, not just listening. This is as much about learning as delivery.”

Why this works:

  • Everyone has work at their level AND a stretch opportunity
  • The senior engineer is explicitly mentoring, multiplying her impact
  • You’ve created learning paths (Sarah learning message handling, Chen learning distributed systems)
  • You’ve made it clear that collaboration and learning are expected outcomes

5. Practice Exercises: Developing Your Mentoring Skills ​

Exercise 1: The Weekly Mentoring Audit ​

How it works: Every Friday, spend 15 minutes reviewing your week:

  • List every mentoring interaction (formal 1-on-1s and informal conversations)
  • For each, score yourself: Did I…
    • Ask more questions than I answered? (Yes/No)
    • Help them think vs. think for them? (1-5 scale)
    • Calibrate to their level appropriately? (Yes/No)
    • Create accountability for their next step? (Yes/No)

Goal: Pattern recognition. You’ll start to see your default tendencies. Do you over-help? Under-challenge? Treat everyone the same?

Exercise 2: The Question Library ​

How it works: Build a personal library of powerful questions for different situations. Start with these, then add your own:

When they’re stuck:

  • “What have you tried so far?”
  • “What would you try if you had to solve this right now?”
  • “What’s your hypothesis about what’s causing this?”

When they’re making a decision:

  • “What are the trade-offs you’re considering?”
  • “What would happen if you chose option A? Option B?”
  • “What concerns you most about this approach?”

When they’re proposing a solution:

  • “Walk me through your thinking.”
  • “What alternatives did you consider?”
  • “How does this align with our architecture principles?”

When they’re frustrated:

  • “What part of this is within your control?”
  • “What would you need to move forward?”
  • “Who else could help with this?”

Practice: In your next five mentoring conversations, use questions from this library instead of giving direct answers. Notice what happens.

Exercise 3: The Delegation Ladder Practice ​

How it works: Take three upcoming tasks or projects. For each:

  1. Identify who you’d assign it to
  2. Write down which delegation level (1-5 from the framework) you’d use
  3. Write the exact words you’d use to delegate it
  4. Have another leader review your delegation language

Example:

  • Task: Implement caching for the reporting service
  • Assignee: Mike (mid-level engineer)
  • Level: 3 (Here’s the problem, you propose a solution)
  • Delegation language: “The reporting queries are slow for large datasets. Users are complaining about 10+ second load times. We need to improve this to under 2 seconds. Investigate the root cause and propose solutions. Consider caching, query optimization, or architectural changes. I’m here to help think through trade-offs, but I want your recommendation. Let’s sync in three days on what you find.”

Exercise 4: The Reverse Shadow ​

How it works: Ask a senior engineer to observe you in a mentoring conversation (with the mentee’s permission). Afterward, have them give you feedback:

  • What did they notice about your question-to-answer ratio?
  • Where did you solve vs. guide?
  • How well did you read the mentee’s level?
  • What did you miss?

Advanced version: Record a mentoring session (with permission), watch it yourself, and critique your own performance.

Exercise 5: The Growth Plan Workshop ​

How it works: For each person you mentor, create a 6-month growth plan:

  1. Current state: What’s their level? What are they good at? Where do they struggle?
  2. Target state: Where should they be in 6 months? What skills/behaviors should improve?
  3. Gap analysis: What’s preventing them from getting there?
  4. Your role: What specific mentoring will help bridge that gap?
  5. Their role: What do they need to do?
  6. Checkpoints: How will you measure progress?

Example from your context:

  • Engineer: Sarah, junior engineer on the Aperia port management system
  • Current state: Solid on basic implementation, follows patterns well, but needs guidance on every architectural decision. Hesitant to propose solutions.
  • Target: In 6 months, can independently design and implement moderate-complexity features with minimal guidance. Proposes solutions confidently even if they need refinement.
  • Gap: Lack of exposure to architectural thinking. Doesn’t understand the “why” behind patterns. Low confidence.
  • Your role: Weekly pairing on architecture decisions (not just implementation). Ask “why” questions constantly. Explicitly connect patterns to principles. Celebrate when she proposes solutions, even imperfect ones.
  • Her role: Study architecture in codebase. Come to code reviews with questions. Propose at least one solution per week, even if uncertain.
  • Checkpoints: Monthly 1-on-1s reviewing progress. By month 3, she should be proposing solutions for her own tickets. By month 6, helping junior engineers.

Exercise 6: The Feedback Practice ​

How it works: Practice giving three types of feedback:

Positive feedback (reinforcement):

  • Find one thing each team member does well this week
  • Tell them specifically, connecting behavior to outcome
  • Template: “When you [specific behavior], it [positive outcome]. Keep doing this because [why it matters].”

Developmental feedback (coaching):

  • Identify one growth area per person
  • Frame as opportunity, not criticism
  • Template: “I’ve noticed [observation]. Here’s why that matters: [impact]. What I’d like to see is [desired behavior]. How can I help you get there?”

Redirecting feedback (correction):

  • When someone makes a mistake or exhibits problematic behavior
  • Be direct but respectful
  • Template: “[Specific behavior] isn’t working because [impact]. Here’s what needs to change: [expectation]. Let’s talk about how to make that happen.”

Practice: Give each type of feedback at least once this week. Write it down first, then deliver it.

Exercise 7: The Mentoring Book Club ​

How it works: Read one book on mentoring, coaching, or leadership development per quarter. Discuss with other technical leads or managers. Books to consider:

  • The Coaching Habit by Michael Bungay Stanier (question-based coaching)
  • Radical Candor by Kim Scott (direct, kind feedback)
  • The Manager’s Path by Camille Fournier (technical leadership)
  • Thanks for the Feedback by Douglas Stone & Sheila Heen (receiving and giving feedback)
  • Multipliers by Liz Wiseman (amplifying others’ intelligence)

After reading, try one new technique for a month and assess results.

6. Key Takeaways: What to Remember ​

The Core Truth ​

Mentoring is about developing their thinking, not transferring your knowledge. Your goal is to make them better problem-solvers, not to solve their problems.

The Level Calibration ​

  • Juniors: Structure + patterns + confidence
  • Mid-levels: Judgment + autonomy + exposure to complexity
  • Seniors: Strategy + influence + organizational thinking
  • Staff+: Vision + leverage + leadership presence

Different levels need fundamentally different things. One size does not fit all.

The Golden Ratio ​

In any mentoring conversation, you should ask 3-5 questions for every 1 answer you give. If you’re doing most of the talking, you’re probably teaching or directing, not mentoring.

The Delegation Principle ​

Move engineers progressively up the delegation ladder:

  1. Do this exactly
  2. Do this, here are options
  3. Here’s the problem, you propose
  4. Here’s the outcome, you decide
  5. You see it, you fix it

Too fast = anxiety. Too slow = frustration.

The Hard Truth ​

Sometimes you need to manage, not mentor. Repeated mistakes, ignored feedback, and performance issues aren’t mentoring opportunities—they’re management issues requiring clear expectations and accountability.

The Multiplication Test ​

Ask yourself: “Am I solving this problem, or am I helping them become someone who can solve this problem?” The first serves the immediate need. The second serves their growth and multiplies your impact.

The Feedback Formula ​

Specific behavior + Impact + Desired outcome + Support

“When you [behavior], it [impact]. What I’d like to see is [outcome]. How can I help you get there?”

Not: “Good job.” But: “The way you handled that unclear requirement—going back to the BA with specific questions rather than making assumptions—that saved us a potential rework cycle. That’s exactly the ownership we need.”

The Long Game ​

Effective mentoring is measured in quarters and years, not days and weeks. You’re building capabilities, judgment, and professional identity. This takes time. Be patient but persistent.

The Mirror ​

The engineers you mentor will eventually mentor others. They’ll pass on your approach—the questions you ask, the standards you hold, the way you balance challenge and support. You’re not just shaping them; you’re shaping the next generation they’ll influence.

Your Action Plan ​

Starting this week:

  1. Identify 2-3 people at different levels to focus on
  2. Create growth plans for each (Exercise 5)
  3. Practice the question library in every interaction (Exercise 2)
  4. Do the weekly audit every Friday (Exercise 1)
  5. Give specific feedback at least 3 times this week (Exercise 6)

This month:

  • Set up regular mentoring conversations (weekly or biweekly)
  • Read one chapter of a mentoring/coaching book
  • Get feedback on your mentoring from a peer (Exercise 4)

This quarter:

  • Review progress on growth plans monthly
  • Adjust your approach based on what’s working
  • Celebrate when you see engineers growing in autonomy and judgment

Final Reflection ​

You’ve spent 15+ years becoming exceptional technically—mastering distributed systems, cloud architecture, microservices across multiple domains. That expertise is your foundation. But as you step into leadership at the Principal/Staff+ level, your impact multiplies through the engineers you develop.

At Aperia, CoverGo, YOLA, and Tricentis, you’ve seen what’s possible when teams have strong technical leaders. You’ve worked across US, EU, and APAC teams. You understand the difference between projects that succeed because of one brilliant engineer versus projects that succeed because the whole team has been developed to think architecturally and make good decisions.

Mentoring is how you create the second kind of team.

It’s also, honestly, harder than solving technical problems. When a system breaks, the debugger shows you the stack trace. When a mentoring approach isn’t working, you have to read subtle human signals, adjust your style, and stay patient while someone struggles toward understanding.

But here’s what makes it worthwhile: Six months from now, that junior engineer will solve a complex problem independently. That mid-level engineer will mentor someone else. That senior engineer will drive technical direction for an entire initiative. And each time that happens, your impact has multiplied.

That’s what makes you not just a senior engineer, but a leader.

Interview Practice: Mentoring Engineers at Different Experience Levels ​

Question 1: "How do you approach mentoring a junior engineer versus a senior engineer?" ​

WHY INTERVIEWERS ASK THIS ​

They want to see if you understand that different experience levels need fundamentally different mentoring approaches. They're checking whether you can calibrate your leadership style and whether you've actually mentored engineers at various levels with thoughtful adaptation.

SAMPLE ANSWER ​

"Honestly, it's two completely different relationships. With junior engineers, I focus on building their foundation—confidence, patterns, how to think through problems. I'll do pair programming sessions where I narrate my thinking out loud. Like, 'I'm checking the logs first because...' That helps them build their own internal problem-solving dialogue. And I give them well-defined tasks with clear success criteria so they can get some early wins.

With senior engineers, it's almost the opposite. They don't need me explaining how to code. They need the bigger picture—why we made certain architectural decisions, how the business strategy connects to our technical choices. I bring them into those conversations, give them ambiguous problems instead of clear specs, and ask their opinion rather than just directing them.

The way I think about it: with juniors, you're saying 'here's how to do this.' With seniors, you're saying 'what do you think we should do?' Same goal—develop them—but completely different approach."

Question 2: "Tell me about a time when you had to mentor an underperforming engineer." ​

WHY INTERVIEWERS ASK THIS ​

They're testing whether you can distinguish between developmental issues (needs mentoring) and performance issues (needs management). They want to see your diagnostic skills, patience, and ability to create improvement plans without avoiding difficult conversations.

SAMPLE ANSWER ​

"I had a mid-level engineer who kept missing quality standards—missing edge cases, skipping tests, not thinking about maintainability. But before I just started pushing harder, I needed to understand why.

I sat down with him and asked: 'Walk me through your process. What's actually hard about this work?' Turned out he wasn't careless—he was overwhelmed by ambiguity. Clear, well-defined features? He did fine. But when requirements were fuzzy, he'd just start coding and hope for the best.

So I changed my approach. Instead of only reviewing his code after the fact, I started meeting with him at the design phase—before he wrote a line. I'd ask: 'What edge cases do you see here? What could break?' That shifted his thinking to earlier in the process.

Within two months, his quality improved a lot. The key insight was that it was a specific skill gap, not a motivation problem. He just hadn't learned how to work with ambiguous requirements. Once I focused on exactly that, he got much better quickly."

Question 3: "How do you help engineers develop their technical judgment and decision-making skills?" ​

WHY INTERVIEWERS ASK THIS ​

This tests whether you understand that judgment is different from knowledge—it's about knowing when to apply which solution. They want to see if you can develop engineers who make good independent decisions rather than engineers who always need you.

SAMPLE ANSWER ​

"The thing about technical judgment is—it doesn't come from learning patterns. It comes from experiencing trade-offs. So when an engineer asks me 'should I use caching here?', I don't just say yes or no. I ask them to think it through. 'What problem are you actually solving? What's the downside of caching? What's the downside of not caching?'

The key is making them do the analysis, not me. For example, if someone's designing an integration with an external service, I'll ask: 'Should this be sync or async?' Then we work through it—'What happens if that service is slow? What if it goes down? Does the user need immediate confirmation, or is reliability more important?' By going through those questions together repeatedly, they eventually start asking those questions on their own.

I also give them safe spaces to practice. I'll have a mid-level engineer own a small feature where they're making the real calls. They can make mistakes at a smaller scale, and I'm there as a sounding board—but they're deciding.

The goal is to build people who think independently, not people who always need to check with me first."

Question 4: "How do you balance giving engineers autonomy while ensuring quality and meeting deadlines?" ​

WHY INTERVIEWERS ASK THIS ​

This question tests your understanding of the delegation spectrum and risk management. They want to see if you can calibrate autonomy based on capability and complexity, and whether you have mechanisms to catch issues early without micromanaging.

SAMPLE ANSWER ​

"I think about it as a delegation ladder—how much autonomy I give depends on two things: the person's level and how critical the work is. A junior on a critical feature? I'll say 'here's the approach, here are the checkpoints.' A senior on the same thing? 'Here's the outcome we need—you design how we get there.' Very different conversations.

The key is building in smart checkpoints—not to micromanage, but to catch problems early when they're cheap to fix. I'll ask for a design review before anyone starts coding. For anything on the critical path, a quick sync at roughly 30% and 70% complete. Not because I don't trust people—just to avoid surprises late in delivery.

Quality standards stay the same for everyone. Tests, code reviews, architecture alignment—that doesn't change. What changes is the support. A junior gets pairing and detailed feedback. A senior gets 'this needs tests—what's blocking you?'

It's really about earned autonomy. As people show good judgment, they get more freedom. If they struggle, I add more structure back—not as a punishment, but as support."

Question 5: "Describe how you've helped an engineer transition from individual contributor to a leadership role." ​

WHY INTERVIEWERS ASK THIS ​

They're checking if you can identify leadership potential and develop it systematically. They want to see if you understand that the IC-to-leader transition requires new skills (influence, delegation, strategic thinking) not just more technical expertise.

SAMPLE ANSWER ​

"I had a senior engineer who was technically excellent but had never really led anything beyond his own code. But I saw potential—he asked sharp questions in architecture meetings, and other engineers naturally came to him for advice.

So I started giving him leadership work incrementally. First, I asked him to drive a technical design involving stakeholders from three different teams. Before he went in, I coached him: 'Your job isn't to have all the answers—it's to ask the right questions and help the group reach a good decision.'

He struggled with that at first. His instinct was to just propose a solution in the first five minutes. I gave him direct feedback: 'What if you'd held back and asked each team about their constraints first?' He adjusted, and the difference was noticeable pretty quickly.

Then I had him mentor two junior engineers, which taught him something important—solving problems for people doesn't actually help them. And finally I had him present our architecture strategy to senior leadership, which forced him to translate technical thinking into business value.

Six months later he was leading initiatives independently. He's now a tech lead on another team."

Question 6: "How do you mentor engineers who are more experienced than you in certain technical areas?" ​

WHY INTERVIEWERS ASK THIS ​

This tests your ego and whether you understand that technical leadership isn't about being the best coder. They want to see if you can add value through context, coordination, and judgment even when you're not the deepest technical expert.

SAMPLE ANSWER ​

"This is actually pretty common, especially as you move into broader technical leadership. You can't be the deepest expert in every domain—and honestly, trying to fake it doesn't help anyone.

When I'm working with someone who knows a domain better than I do, my value shifts. I'm not competing on technical depth. I'm asking questions that connect their work to the bigger picture—things like: 'How does this affect other services? What's the operational overhead? Does this align with where our platform is heading?' That's where I genuinely add something.

I also look for ways to amplify their expertise—getting them to do tech talks, write documentation, mentor others. My job is to remove obstacles and create leverage for what they already know, not compete with it.

And honestly, it goes both ways. They're teaching me about their domain, and I'm coaching them on navigating organizational complexity or handling ambiguous situations. The best technical leads aren't the smartest person in the room—they're the ones who make sure everyone's expertise actually gets used."

Question 7: "What's your approach when an engineer disagrees with your technical guidance?" ​

WHY INTERVIEWERS ASK THIS ​

They're testing whether you have ego issues and whether you create a safe environment for technical debate. They want to see if you can distinguish between good pushback (engineer sees something you missed) versus lack of context (engineer doesn't understand constraints).

SAMPLE ANSWER ​

"Honestly, I like when engineers push back. It usually means they're thinking deeply rather than just nodding along. So my first instinct is always to understand their reasoning, not defend my position.

I'll ask: 'Walk me through your thinking—what specifically are you concerned about?' Then I actually listen. Sometimes they're right. They have context I don't, or they've spotted an edge case I missed. When that happens, I change course or we blend the ideas. And that happens more than you'd think.

Other times, the disagreement is really a context gap. For example, an engineer once pushed back on my recommendation to use a message queue, saying sync calls were simpler. He was right about simplicity—but he didn't know about our reliability history and the times those external services had gone down at critical moments. So I shared that context: 'Here's the history and why reliability beats simplicity in this case.' Once he understood, it made sense.

The key is treating disagreement as information, not opposition. And if I've explained my reasoning and they still disagree, I'll sometimes say 'Let's try it this way and revisit in two weeks.' That keeps the door open and shows I could still be wrong."

Question 8: "How do you identify which engineers are ready for more responsibility?" ​

WHY INTERVIEWERS ASK THIS ​

They want to see if you have a systematic way to evaluate readiness rather than just promoting based on tenure or who asks loudest. They're checking if you understand the difference between being good at current level versus ready for next level.

SAMPLE ANSWER ​

"I look for three things: they're solid at their current level, they're already showing some next-level behaviors naturally, and they actually want the growth.

The first one matters more than people realize. If someone still needs a lot of direction on their current responsibilities, they're not ready for more—even if they're enthusiastic or have been around a long time.

The second signal is watching for next-level behaviors that show up on their own. A mid-level who's ready to move toward senior will start mentoring juniors without being asked, or they'll propose improvements outside their immediate area. They're not just doing their job—they're already doing a bit more.

Third, I have a direct conversation about their goals. Some engineers genuinely don't want leadership responsibility—they want to go really deep technically, and that's completely fine. Not everyone should be climbing the same ladder.

When those signals align, I create a test opportunity. Give them something at the next level—lead a design session, handle a tricky stakeholder relationship—and see how they handle it with some coaching. If they succeed, they're probably ready. If they struggle significantly, they need more development time. The key is evaluating this systematically rather than going on gut feel or promoting whoever asks most loudly."

Question 9: "Tell me about a time when your mentoring approach didn't work. What did you learn?" ​

WHY INTERVIEWERS ASK THIS ​

This tests self-awareness and adaptability. They want to see if you can recognize when something isn't working, reflect on why, and adjust your approach. It also shows whether you blame the engineer or take responsibility for finding what works.

SAMPLE ANSWER ​

"I was mentoring a mid-level engineer using my usual approach—Socratic questions, minimal direct guidance, letting him work through problems. It works really well with most people, but after a month he wasn't improving and seemed genuinely frustrated.

I finally just asked him directly: 'How is this actually working for you—is this helpful?' He said he felt lost. That my questions felt more like tests than help. He needed to see examples first, then practice applying them.

And I realized I had been doing what works for me, not what works for him. That's a pretty easy trap to fall into. So I adjusted—I started showing him examples from our codebase first, then giving him similar problems to solve. Results improved quickly.

The real lesson was: you have to adapt to how they learn, not just use the approach you know best. Some people need to see the pattern before they can practice it. Others need to struggle first and then see the solution. Some need to talk it through, others need to write things down. Now I ask early on—'How do you learn best?' And if something isn't working after a few weeks, that's my signal to change my approach, not push harder with the same one."

Question 10: "How do you scale your mentoring when you're responsible for multiple engineers at different levels?" ​

WHY INTERVIEWERS ASK THIS ​

They're testing whether you understand leverage and systems thinking. Can you create structures that develop people without requiring you to personally mentor everyone individually? This is crucial for senior leadership roles.

SAMPLE ANSWER ​

"You can't deeply mentor everyone individually—that doesn't scale. So I focus on creating systems and leverage.

The biggest leverage I get is mentoring cascades. I mentor senior engineers explicitly on how to mentor, and they carry that forward to mid-levels and juniors. When I'm coaching a senior, I'll actually say: 'Notice how I'm asking questions rather than giving answers? That's intentional—use that same approach when your team comes to you.' The mentoring multiplies.

Second, I use group learning whenever it makes sense. If I'm going to explain the same architectural principle in five separate conversations, I'm better off doing a team tech talk or writing good documentation with clear examples. It scales better and gives people something to reference later.

Third, I protect my personal time for high-leverage moments—design reviews where multiple people are learning at once, critical career transition points, first-time leadership situations. Those are worth my direct attention. But a mid-level debugging a familiar type of issue? That's what documentation and peer pairing are for.

And finally, I build structures—regular architecture reviews, pairing rotations, a culture where asking questions is normal and expected. When the system is healthy, development happens all the time, not just in my one-on-ones."

Released under the MIT License.

Copyright © 2026 LCN