The hardest part of mentoring isn’t technical. It’s resisting the urge to just give the answer.

When a junior developer gets stuck, the fastest solution is for you to explain what to do. But that doesn’t develop them — it develops their dependency on you. The slower, harder path is asking questions that make them figure it out. That’s what actually builds engineers.

For Vietnamese tech leads working in English, this challenge is compounded by language. It’s tempting to default to direct instructions in English because coaching questions feel harder to phrase correctly. But the investment is worth it. Here’s the English for mentoring that develops, not just unblocks.

The Core Mentoring Shift: From Telling to Asking

The fundamental technique is Socratic questioning — instead of saying what to do, asking questions that lead the engineer to figure it out themselves.

Telling (fast, but doesn’t teach):

“The problem is that you’re not handling the null case. Add a guard clause before this line.”

Asking (slower, but builds capability):

“What do you think happens if user is null here? Walk me through it.”

The asking version does several things the telling version doesn’t:

  • Forces the engineer to engage their reasoning, not just follow instructions
  • Reveals where their understanding actually breaks down
  • Builds the habit of asking “what could go wrong” rather than waiting to be told
  • Gives you diagnostic information about their current mental model

The key is that your question must be genuine — not a rhetorical lead toward the answer you already have, but a real invitation to think through the problem.

Opening a Mentoring Conversation

How you start a mentoring conversation sets the tone for whether the junior will think or wait to be told.

Weak opener (puts you in charge):

“So here’s what you need to do…”

Strong opener (puts them in the problem):

“Before I share what I’m seeing, tell me: what’s your read on where this is going wrong?”

Other strong openers:

  • “Walk me through your thinking on this approach.”
  • “What have you tried so far? And why did each thing not work?”
  • “If you had to guess what the root cause is, what would you say?”
  • “What would you do differently if you were starting this from scratch?”

These questions don’t have right or wrong answers — they’re designed to surface how the engineer thinks. That’s the information you need to mentor them effectively.

When They’re Stuck: Guiding Without Rescuing

Sometimes a junior is genuinely blocked and needs direction, not just questions. The art is in calibrating how much to give.

Level 1 — hint (they need a small nudge):

“You’re on the right track. Have you looked at what happens in the auth service when the token is expired?”

Level 2 — direction (they need a clearer path):

“I’d focus on the error handling path first — what happens when the API returns a 401? Trace that through.”

Level 3 — direct answer + explanation (they genuinely can’t proceed):

“In this case, the issue is the middleware order. The auth check runs after the route handler, so by the time it tries to validate the token, the request has already been processed. Here’s why that matters: [explanation]. Does that make sense? What would you change?”

Notice that even Level 3 ends with a question. The goal is for them to complete the loop — not just receive information, but confirm they’ve understood it well enough to apply it.

Giving Feedback That Sticks

Feedback in mentoring is different from code review feedback. It’s developmental — the goal is to change how the person thinks, not just fix this particular piece of work.

Feedback that fixes the immediate thing:

“Add error handling here.”

Feedback that changes the pattern:

“I notice this code assumes the API always responds successfully — and this is the third time I’ve seen that assumption in your work. Let’s talk about a mental model for always considering failure paths. What would be the questions you’d ask yourself to catch this proactively?”

The second version is longer, but it addresses the root cause (missing mental model) rather than the symptom (missing error handling). Done right, you have this conversation once rather than leaving the same review comment 10 times.

The feedback formula for mentoring:

  1. Observe — what you actually saw, specifically
  2. Impact — why it matters in this context
  3. Pattern — is this a one-off or part of a broader gap?
  4. Question — what’s their explanation? What do they think the right approach is?

“I’ve noticed [specific observation]. In this case, that means [impact]. This is something I’ve seen come up a few times in your work — I’m curious what your thinking is when you approach [related scenarios]. How do you decide when to [relevant technical judgment]?”

Setting Growth Expectations Clearly

Junior developers often don’t know what “good” looks like or what the milestones are. Part of your job is making that explicit.

Vague expectation:

“I want you to get better at system design.”

Specific expectation:

“Over the next two months, I want you to get to a point where you can break down a feature into its components, identify the data flow, and flag the edge cases without prompting. The next time we have a new feature, I’d like you to do that analysis first and bring it to our 1-on-1. We’ll review it together.”

The specific version answers: what does “better” look like, what’s the timeline, and what’s the concrete deliverable they’ll be evaluated on?

When you close a mentoring session, always end with:

“What’s your takeaway from this conversation? What will you do differently next time?”

Asking them to articulate the lesson in their own words is the most reliable way to confirm it actually landed.

🗣️ Key Phrases to Say Out Loud

  1. “Walk me through YOUR THINKing on this apPROACH” /wɔːk miː θruː jər ˈθɪŋkɪŋ ɒn ðɪs əˈprəʊtʃ/ — Open a mentoring conversation; puts the engineer in the problem

  2. “What do you THINK happens if [X] is NULL here?” /wɒt duː juː θɪŋk ˈhæpənz/ — Socratic question for debugging; forces them to trace the logic

  3. “You’re on the RIGHT TRACK — have you LOOKED at…” /jər ɒn ðə raɪt træk/ — Level 1 hint; validates direction while nudging forward

  4. “I’d FOCUS on the ERROR HANdling PATH first” /aɪd ˈfəʊkəs ɒn ðə ˈerər ˈhændlɪŋ pɑːθ/ — Level 2 direction; gives clear next step without full answer

  5. “This is the THIRD time I’ve SEEN that ASSumption” /ðɪs ɪz ðə θɜːd taɪm aɪv siːn ðæt əˈsʌmpʃən/ — Pattern-level feedback opener; signals this is a recurring gap

  6. “What’s your TAKEaway from THIS conversation?” /wɒts jər ˈteɪkəweɪ frəm ðɪs ˌkɒnvəˈseɪʃən/ — Close every mentoring session; confirms understanding

  7. “How do you deCIDE when to [X]?” /haʊ duː juː dɪˈsaɪd wɛn tə/ — Surfaces their decision-making process; reveals where judgment is missing

📚 Vocabulary

1. Socratic /səˈkrætɪk/ (adjective)

  • Meaning: A teaching method using questions to develop critical thinking, named after philosopher Socrates
  • Example: “I try to use Socratic questioning in mentoring — instead of giving answers, I ask questions that lead the junior to figure it out.”

2. Scaffold /ˈskæfəʊld/ (verb, in education/mentoring)

  • Meaning: To provide structured support that enables someone to do something they couldn’t do alone, then gradually remove the support
  • Example: “In the first month, I scaffold their architecture decisions. By month three, they should be making them independently.”

3. Unblock /ʌnˈblɒk/ (verb)

  • Meaning: To remove an obstacle preventing someone from making progress
  • Example: “My goal in a mentoring conversation isn’t just to unblock them — it’s to develop their ability to unblock themselves.”

4. Takeaway /ˈteɪkəweɪ/ (noun)

  • Meaning: The key lesson or insight someone takes from a conversation or experience
  • Example: “At the end of every 1-on-1, I ask: what’s your takeaway? It’s the only way to know if the message actually landed.”

5. Root cause /ruːt kɔːz/

  • Meaning: The underlying fundamental reason for a problem (versus a symptom)
  • Example: “The missing error handling is the symptom. The root cause is that they don’t have a mental model for thinking about failure paths.”

6. Calibrate /ˈkælɪbreɪt/ (verb)

  • Meaning: To adjust or fine-tune something to the right level for a specific situation
  • Example: “I calibrate how much direction I give based on how blocked they are — sometimes a hint is enough, sometimes they need the full answer.”

7. Dependency /dɪˈpɛndənsi/ (noun)

  • Meaning: A state of relying on someone or something; in mentoring, when a junior relies on the senior for answers instead of thinking independently
  • Example: “If I always give the answer immediately, I’m building dependency, not capability.”

🎯 Practice Now

Exercise 1: Telling → Asking Conversion

Convert each “telling” statement into a Socratic question. Say your questions aloud.

  1. “You should use a Map instead of a list for O(1) lookups.”
  2. “The bug is in the retry logic — you’re retrying on 400 errors when you should only retry on 5xx.”
  3. “This function is doing too many things — it should be split up.”
  4. “You need to add a database index on this column for the query to be fast.”

Sample conversions:

  1. → “If this list had 100,000 items and you needed to do this lookup 1,000 times, what would concern you about the current approach?”
  2. → “Walk me through your thinking on which HTTP status codes should trigger a retry. What’s the difference between a 400 and a 503?”
  3. → “Can you tell me the single responsibility of this function? What’s the one thing it does?”
  4. → “What happens to this query as the table grows to 10 million rows? How would you find out?”

Exercise 2: Three-Level Response Practice

For the same problem (“the junior’s API call has no timeout, causing requests to hang indefinitely”), practice all three levels:

  • Level 1 (hint): Say a one-sentence hint that points them in the right direction without naming the problem.
  • Level 2 (direction): Give a clearer direction that names the area to investigate.
  • Level 3 (answer + explanation): Give the full answer, then ask them a question to confirm understanding.

Say each level aloud. Notice how the amount of information changes, but the closing question stays.

Exercise 3: Pattern Feedback Script

Write and say aloud a piece of pattern-level feedback using this structure: “I’ve noticed [specific observation]. This is [how many times] I’ve seen [the pattern]. I’m curious — [question about their thinking]. What would be the questions you’d ask yourself to [catch it proactively]?”

Use a real or imaginary scenario from your team.

The best mentors don’t produce engineers who think like them. They produce engineers who think better than they would have otherwise. That shift — from sharing answers to asking better questions — is available to every tech lead who practices it deliberately.

The English for it is learnable. The habit is worth building.

Export for reading

Comments