Mentoring Mid-Level Engineers — How to Help Them Cross the Senior Threshold

Common gaps between mid-level and senior:

Technical ownership:
→ Mid: "My code works"
→ Senior: "My code is deployed, monitored, documented, and the on-call
   engineer knows how to debug it"

System thinking:
→ Mid: Designs the solution for the requirement
→ Senior: Designs the solution AND considers failure modes, edge cases,
   scale implications, and maintainability in 2 years

Communication:
→ Mid: Updates when asked
→ Senior: Proactively flags blockers, trade-offs, and scope changes

Ambiguity handling:
→ Mid: Asks for clarification on every ambiguous requirement
→ Senior: Makes reasonable assumptions explicit, proceeds, and verifies

Debugging approach:
→ Mid: Follows stack traces to fix the immediate error
→ Senior: Asks "why did this condition exist?" and fixes the root cause

Code review:
→ Mid: Checks correctness
→ Senior: Considers architecture, observability, error handling, and
   the reviewer's ability to understand the change

// growth-plan-template.ts
interface GrowthGoal {
  behavior: string
  currentState: string
  targetState: string
  practiceOpportunities: string[]
  milestoneIndicator: string
}

const seniorGrowthPlan: GrowthGoal[] = [
  {
    behavior: 'System impact thinking',
    currentState: 'Designs solutions that work for the immediate requirement',
    targetState: 'Proactively identifies how changes affect adjacent systems before coding',
    practiceOpportunities: [
      'For the next 3 PRs: write a "this change affects..." comment before starting',
      'Lead a design review for a medium-complexity feature',
      'Review another engineer\'s design and identify 3 downstream considerations',
    ],
    milestoneIndicator: 'Points out downstream impacts unprompted in design discussions',
  },
  {
    behavior: 'Proactive communication',
    currentState: 'Updates status when explicitly asked',
    targetState: 'Sends daily async update on multi-day work, flags blockers same day',
    practiceOpportunities: [
      'On current project: send daily async update (Slack or GitHub comment) without being asked',
      'Flag blockers within 2 hours of identifying them, not at end-of-day standups',
    ],
    milestoneIndicator: 'Teammates and manager comment that they always know where things stand',
  },
  {
    behavior: 'Full ownership of shipped features',
    currentState: 'Considers work done when PR is merged',
    targetState: 'Adds monitoring, documentation, and on-call runbook before marking done',
    practiceOpportunities: [
      'For the next feature: write the runbook before deploying',
      'Add a CloudWatch alert for the feature you shipped last month',
      'Update the team wiki with your system\'s operational documentation',
    ],
    milestoneIndicator: 'On-call engineers can debug issues in their systems without asking',
  },
]

// When a mid-level engineer makes a mistake in code review,
// resist the urge to just fix it for them

// ❌ Ineffective mentor response:
// "This will cause N+1 queries. Change it to:
// const users = await User.findAll({ include: ['orders'] })"

// ✅ Effective mentor response:
// "What happens to this query when there are 1000 orders?
// Let's look at the SQL this generates together."
// → Engineer discovers the issue
// → Engineer researches eager loading
// → Engineer fixes it with understanding they'll retain

// Scaffolded questions instead of answers:
const mentoringQuestions = {
  'performance issue': 'How many database queries does this code make per request? What happens at 10,000 users?',
  'error handling': 'What happens if $service is unavailable? How does the caller know something went wrong?',
  'observability': 'When this fails at 3 AM, what information will the on-call engineer need?',
  'design review': 'What will this code look like if we need to change the business logic in 6 months?',
  'testing': 'How do you know this works? What would need to be true for it to fail silently?',
}

// The goal: engineer asks themselves these questions without the mentor present

Ineffective delegation:
"Can you work on the rate limiting feature?"
→ Engineer builds a rate limiter but misses that it needs to be distributed,
   didn't consider the UX for rate-limited users, doesn't know the scale requirement.

Effective delegation:
"I'd like you to lead the rate limiting feature. Here's the context:
- Business requirement: prevent abuse on the signup endpoint
- Scale: needs to work across 10 server instances (distributed)
- Users affected: 0.1% of users (only abusive requests)
- You'll need to handle the UX for rate-limited users (what message, retry info)
- Dependencies: Redis is available, existing middleware setup is in auth.ts
- Success criteria: I should be able to add a rate limit to any endpoint in 5 minutes

Questions for you before you start:
1. What are the different ways to implement this?
2. What are the trade-offs?
3. What information do you need that you don't have?

Check in after your design doc, then again after the first working version."

The delegation includes: context, constraints, success criteria, explicit unknowns,
and specific check-in points — not just the task.

Useless career conversation:
Manager: "Where do you want to be in 5 years?"
Engineer: "Um... senior engineer? Maybe staff someday?"
Manager: "Great, keep doing good work!"
→ Nothing changes

Useful career conversation:
Manager: "I've noticed you're technically strong, and I want to help you move toward senior.
The specific gaps I see are: [1, 2, 3].
Here's what I think doing senior-level work on those gaps looks like: [specific behaviors].
I'd like you to lead the next architectural decision — here's what I'll look for:
you should proactively identify trade-offs before I ask, and you should write
a brief document capturing the decision rationale. I'll give you feedback after.
Does that sound like a fair way to practice this?"

The useful version:
- Names specific gaps (not "think bigger")
- Describes the target behavior concretely
- Creates a specific opportunity to practice
- Commits to specific feedback
- Gets buy-in from the engineer

Scaffolded skill transfer:

Stage 1: I Do (you observe)
→ Senior engineer leads a design review
→ Mid-level engineer watches, takes notes, asks questions afterward
→ Explicit teaching points: "Notice I asked about failure cases before
   discussing the happy path. I do this because..."

Stage 2: We Do (you lead, I support)
→ Mid-level engineer leads the next design review
→ Senior engineer is in the room, can interject if needed
→ Debrief after: "What questions did you ask? What did you miss?
   Next time, consider asking about..."

Stage 3: You Do (independent)
→ Mid-level engineer leads design review independently
→ Shares notes with senior for async feedback
→ Senior validates and identifies any remaining gaps

This model works for: code review, incident response, design reviews,
stakeholder communication, technical interviews they're running.