Mentoring, Feedback, and Helping Others Grow

Senior engineers don’t just write code — they multiply other engineers. Interviewers ask about mentoring to see if you operate at the team level, not just the individual level.

What they’re really asking

Do you see other engineers’ growth as part of your job?
Can you give feedback that’s honest, specific, and actionable?
How do you handle giving difficult feedback?
Have you actually helped someone grow, and can you point to the change?
Are you safe — do people come to you, or avoid you?

“Tell me about a time you mentored someone”

The strongest answers are specific:

A specific person (anonymized or by role).
A specific area of growth.
What you actually did (not just “I supported them”).
What changed — measurable or observable.

Example template

Situation: Mid-2023, a junior engineer joined my team — 6 months out of bootcamp, strong instincts but new to production codebase work. Their first few PRs had a pattern: lots of small, incremental commits with messages like “fix” and “wip,” code that solved the immediate problem but missed edge cases, and tests that were tightly coupled to implementation.

Task: They wanted to grow toward mid-level fast. I was their tech lead.

What I did:

Made it explicit. In our first 1:1, I said: “Here are three patterns I see in your work; here’s what ‘mid-level’ looks like; here’s what I’d focus on.” Not vague encouragement — three specific things.

Paired on a hard ticket in week 2. Not pairing where I drive; pairing where they drive and I commentate. Watched them debug a flaky test; pointed out two strategies they hadn’t tried.

Reviewed their PRs heavily. Inline comments with the why, not just “do this.” Pointed at the team’s existing code as reference. Asked questions: “What happens if X is empty here?” rather than “you forgot to handle empty case.”

Recommended specific reading. A blog post on writing tests against behavior not implementation. Two PRs in our codebase that showed the pattern well.

Gave hard feedback when needed. Three months in, their commits were still messy. I told them clearly: “This is the one thing I haven’t seen improvement on; here’s exactly what I’d do; here’s why it matters for your career.” Direct, not harsh.

Result: Six months in, they were operating at solid mid-level. PRs were structured, tests covered edges, commits told a story. They asked for stretch work on a critical service migration; I felt comfortable giving it. Two years later (they’re still on the team), they now do for newer engineers what I did for them.

Lesson: Feedback that’s specific, with examples, repeated until it sticks, and balanced with hard truths when needed, is how juniors grow. Vague “you’re doing great” is harmful — it tells someone they’re done growing when they’re not.

What this answer signals

Specific patterns, not generic praise.
Investment in their growth, not just task supervision.
Hard feedback delivered with care. Not avoided.
Measurable change — stretch work, mid-level operating, mentoring others.
Lesson generalizes. You learned something about feedback in general.

Anti-patterns

“I’m a great mentor — people love working with me”

No specifics. Could be true; could be self-flattery. Interviewers want evidence.

“I just answered their questions when they asked”

Reactive. Mentoring is proactive — noticing patterns, surfacing growth areas, pointing at things people couldn’t see themselves.

“I told them everything I would have done differently”

Mentoring isn’t “make them clone of you.” It’s helping them grow into who they’re becoming. The right answer to “what would you do?” is sometimes “tell me what you’ve considered.”

“We had weekly 1:1s”

Mechanism without content. Plenty of weekly 1:1s are useless. What did you actually do in them?

“They moved to a different team and got promoted”

Doesn’t prove your mentoring helped. Maybe they would have grown regardless. The signal is the change you can point to, in behavior, not just an outcome.

“How do you give difficult feedback?”

A separate question, asked often. Strong answers include:

The structure

Specific behavior, not personality. “I noticed in the last three PRs…” not “You’re sloppy.”
Impact, not interpretation. “This causes the reviewer to take 20 minutes instead of 5” not “You’re wasting our time.”
Path forward, not just criticism. “Here’s what I’d try instead…” or “What do you think would help?”
Direct, not hedged. Don’t burying the feedback in 5 minutes of unrelated praise.

Example phrasing

Bad: “I’m not sure if this is just me, but your PRs sometimes seem a bit… messy? Don’t worry about it, just something to think about.”

Good: “I want to share something specific. The last three PRs had commits like ‘wip’ and ‘fix’ — and a reviewer can’t tell what changed in each. The team’s convention is one logical change per commit, with a descriptive message. Here’s an example from last week that does it well: [link]. Does that make sense as something to adjust?”

The good version is direct, specific, has an example, and asks for buy-in. The bad version softens until the feedback is invisible.

Timing

Soon after the event — not three months later in a performance review.
In a 1:1 or DM, not in front of the team.
Spread out if there are multiple things — too much at once becomes paralyzing.

The hardest feedback: when someone needs to leave

If a teammate isn’t going to make it on the team, you’ve done them no favors by hiding it. Give them honest feedback early enough that they can change course (or move on with dignity). The kind thing isn’t always the nice thing.

“How do you receive feedback?”

Adjacent question. Strong answers:

“I ask for it actively, not just receive it when offered.”
“I try to separate the message from the delivery — even if it’s poorly delivered, often the content is valid.”
“I confirm I heard them right before defending. Often I realize they’re saying something different than I assumed.”
“I follow up later: ‘Hey, you mentioned X — here’s what I changed; does this feel like the right direction?’”

The signal is: feedback is something you actively manage, not something that happens to you.

Specific mentoring stories to have ready

Have 2-3 stories pre-thought for common variations:

Mentored a junior — onboarding, building skills, growing into mid-level.
Coached a peer — different team, helped them through a hard problem or career decision.
Pushed back on a senior — junior version giving feedback up isn’t easy; show you can.
Helped someone who was struggling — performance concerns; honest conversation; what changed.
Helped someone leave gracefully — recognized the fit wasn’t there; supported their transition.

A bad answer

“I mentor people by example. Junior engineers learn from watching me write good code.”

Why it fails: passive, not active. Sees mentoring as “be a role model” rather than “actively invest in someone’s growth.” Senior engineers are deliberate about mentoring.

A great answer is observable

The interviewer should be able to picture:

The 1:1 conversation where you said the hard thing.
The PR comment that taught a concept.
The Slack message offering to pair.
The reading list you shared.
The growth trajectory you can describe in specifics.

Reflective practice

Before the interview, list:

Three engineers you mentored. What was the specific growth?
Three pieces of feedback you gave that landed well. What made them land?
Three pieces of feedback you gave that didn’t land. What did you learn?
A piece of feedback you received that changed how you work. How did the deliverer make it land?

Interview angle

Senior engineers are force multipliers. The interviewer wants to know: when you join the team, do other engineers grow because you’re here? Can you have hard conversations without damage? Will you invest in the team or just optimize your own work?

The most senior engineers think about team capability as part of their job description. Show that you do.