Skip to main content

Mentoring Engineers

Prerequisites: Running QA Teams Leads to: After this, you'll be ready for Delegation and Decision Making.

Why This Matters​

A senior engineer who mentors by giving answers. A junior tester asks a senior colleague how to approach testing a complex new feature. The senior engineer, wanting to be helpful, walks through the exact test cases they'd write themselves. The junior tester executes them well — but faced with a similarly complex feature three months later, with no senior engineer immediately available, has no idea how to start, because they were never shown how to arrive at those test cases, only given the destination.

A senior engineer who mentors by building judgment. A peer facing the same question instead asks the junior tester what they think the riskiest parts of the feature are, and why — then works through the reasoning together, correcting and adding to their thinking rather than replacing it. It takes longer in the moment. Three months later, facing a new complex feature alone, that same junior tester works through a similar reasoning process independently, because they were taught the process, not just given a single answer.

Both senior engineers wanted to help. Only one actually built the junior engineer's own capability — because effective mentoring transfers judgment and process, not just answers, even though answers feel more immediately helpful.

Mentoring Is Building Judgment, Not Transferring Answers​

The single most important mentoring principle: a mentee who can only reproduce what they were told hasn't actually grown; a mentee who can reason through a new, similar problem has. This means mentoring conversations should center on questions that surface the mentee's own reasoning — "what do you think the risk is here, and why" — rather than direct instructions, even when a direct instruction would be faster in the moment.

This doesn't mean withholding answers entirely. When a mentee is missing foundational knowledge they couldn't reasonably be expected to have yet, direct teaching is appropriate. The judgment call is distinguishing "they don't yet have the process to work this out" (teach directly) from "they have the process but haven't yet applied it here" (guide them through applying it themselves).

Adapting to Where Someone Actually Is​

Effective mentoring calibrates to the mentee's actual current level, not a generic approach applied uniformly:

  • A new tester with little experience: needs more direct teaching of foundational concepts and more structured guidance, since they genuinely lack the process to reason through unfamiliar problems yet.
  • A tester with solid fundamentals but limited experience with a specific domain or technique: benefits most from guided questions that help them apply what they already know to the new context.
  • An experienced tester developing toward their own leadership role: benefits from being handed genuinely difficult, ambiguous problems with support available but not offered by default — the same "reach for the hardest unowned problem" pattern from Developing Leadership Skills and Technical Credibility, now deliberately created as a mentoring opportunity rather than found independently.

Common Mistakes​

Mistake 1: Always giving direct answers because it's faster in the moment. This module's opening scenario — speed in the moment costs the mentee's actual growth, and the same question resurfaces every time a similar problem arises, since the underlying reasoning was never transferred.

Mistake 2: Applying the same mentoring approach regardless of the mentee's actual level. Guided questioning aimed at someone who genuinely lacks foundational knowledge yet just produces frustration and confusion — calibrate the approach to where the person actually is, not a one-size-fits-all method.

Mistake 3: Mentoring only through scheduled, formal sessions. The most valuable mentoring often happens in the moment — during a code review, a test-case discussion, a postmortem — not only in a scheduled 30-minute meeting; treating mentoring as confined to formal sessions misses most of the actual opportunity.

Mistake 4: Never checking whether the mentoring approach is actually landing. Assuming a mentee has internalized guidance without confirming it, through a follow-up question or observing their next independent attempt, risks continuing an approach that isn't actually working.

Best Practices​

Practice 1: Ask "what do you think, and why" before offering your own answer. This single habit is the core mechanism of judgment-building mentoring — it surfaces the mentee's actual reasoning, which is what you're actually trying to develop.

Practice 2: Calibrate directness to the mentee's actual current level, not a fixed personal style. A mentor who's naturally more directive should deliberately practice guided questioning with a more experienced mentee, and vice versa — the right approach depends on the person, not the mentor's habitual style.

Practice 3: Look for mentoring opportunities in everyday work, not only scheduled sessions. A code review comment, a quick question during standup, or a postmortem discussion are all real mentoring opportunities — treat them as such rather than reserving mentoring for formal time.

Practice 4: Deliberately hand experienced mentees difficult, ambiguous problems, with support available but not automatic. This creates the same credibility-building opportunity Developing Leadership Skills and Technical Credibility describes, but as a deliberate mentoring choice rather than something the mentee has to find on their own.

From the Field

At AtlasBank, a Staff QA Engineer mentoring a junior tester on the Internet Banking team noticed the junior tester kept asking the same category of question — how to determine test priority when a feature touched multiple systems — despite having been given a direct answer for several similar cases before. Recognizing that direct answers hadn't actually built the underlying judgment, the Staff Engineer switched approach: for the next several similar questions, they asked the junior tester to walk through their own risk reasoning first, only correcting and refining rather than replacing it. Within a month, the junior tester was independently applying sound risk-based prioritization to new, previously unseen scenarios — the actual goal direct answers had never achieved, despite being individually correct every time they were given.

Mini Challenge​

Scenario: A junior tester on your team asks you, for the third time this month, how to decide which edge cases matter most for a new feature.

Your task: Write the specific guided questions you'd ask instead of giving a direct answer, designed to help them develop their own reasoning process for this type of decision.

Key Takeaways​

  • Effective mentoring transfers judgment and reasoning process, not just answers — a mentee who can only reproduce what they were told hasn't actually grown.
  • Mentoring approach should calibrate to the mentee's actual current level, not apply a single fixed style uniformly.
  • Most valuable mentoring happens in everyday work moments, not only in scheduled sessions.
  • Deliberately handing experienced mentees difficult, ambiguous problems, with support available, builds their credibility and judgment simultaneously.

What You Just Learned​

  • Why mentoring should build judgment and process, not just transfer answers
  • How to calibrate mentoring approach to a mentee's actual current level
  • Where the most valuable mentoring opportunities actually occur in everyday work
  • The AtlasBank example of shifting from direct answers to guided reasoning

Interview Questions​

Q1: How do you mentor a junior engineer who keeps asking you the same type of question?

What to look for: An answer describing a shift toward guided questioning that builds independent reasoning, not just "I explain it again more clearly" — the strongest answers recognize repeated questions as a signal the underlying process wasn't transferred.

Q2: How do you adapt your mentoring style to different people?

What to look for: Specific examples of calibrating approach to someone's actual level (more direct teaching for genuine knowledge gaps, more guided questioning for applying existing knowledge) rather than a single described style applied to everyone.

Common Interview Mistake

Many candidates describe mentoring purely in terms of being available and answering questions when asked. A strong answer goes further, describing a deliberate method for building the mentee's own reasoning — not just responsiveness, but a specific approach to how answers are given.

Q3: Tell me about a mentoring relationship where you saw someone genuinely grow. What did you do differently?

What to look for: A real example showing a shift in approach over time, ideally connected to the mentee developing independent judgment on a specific type of problem, not just general encouragement.

Glossary​

Judgment-Building Mentoring: An approach that develops a mentee's own reasoning process through guided questions, as distinct from directly transferring answers.

Guided Questioning: Asking a mentee what they think and why, before offering a correction or answer, to surface and develop their own reasoning.

Quick Revision​

Remember these five points:

✓ Effective mentoring transfers judgment and process, not just answers — direct answers alone don't build independent capability.

✓ Mentoring approach should calibrate to the mentee's actual current level, not apply a single style uniformly.

✓ "What do you think, and why" before offering your own answer is the core mechanism of judgment-building mentoring.

✓ Most valuable mentoring happens in everyday work moments — code reviews, standups, postmortems — not only scheduled sessions.

✓ Deliberately handing experienced mentees ambiguous problems, with support available, builds both credibility and judgment.