“Tell me about a time you mentored someone” asks for one thing. The interviewer wants evidence that another engineer got better because of you. A formal mentee isn’t required. Code review, onboarding a new hire or pairing on a hard ticket all count. The story just has to cover weeks, not one afternoon. Build the answer around four facts. Say what the other engineer couldn’t do yet. Say what you changed in how you helped them. Then name something they later did without you. Finish with something you stopped doing because they no longer needed it. Most answers stop after the second fact. They describe a mentoring style, like pairing or regular one-on-ones. An interviewer can’t check a style. They can check what changed for the other engineer. This post follows one Android engineer who never held a mentor title. The story is about a junior teammate whose screens kept losing user input.
For senior roles, the mentoring question checks a written expectation
Some companies write mentoring into their senior job expectations. GitLab publishes an engineering career framework for senior engineers. The page was last updated in March 2026. Its list for the senior level includes “Acts as a Coach and Mentor to others.” Amazon’s leadership principles cover it under Hire and Develop the Best. The page carries no date. That principle says leaders “take seriously their role in coaching others.”
Gergely Orosz describes the same pattern at Uber in a Pragmatic Engineer post. It first ran in 2019 and was updated in September 2026. He writes that mentoring was an expectation for senior engineers there. It was listed in the engineering competencies.
So at senior level, the interviewer has a line on a scorecard to fill. A vague answer leaves that line empty. A specific one gives them a sentence to write down.
Informal mentoring counts when the story has a before and an after
Orosz also writes that he had never put the mentoring label on anything before Uber. Looking back, he had paired with a senior engineer as a junior. He had also helped new teammates learn a codebase. He calls code reviews “frequent examples of informal mentorship.”
That gives most engineers a story. The risk is picking a moment instead of a span. Answering one question in a pull request is helping. Mentoring needs a pattern you noticed and a change over several weeks. It also needs a point where your help was no longer needed.
Test a candidate story with one question. Can you name something the other person did later, without you, that they couldn’t do at the start? If you can’t, pick another story. Without that later act, nothing shows the other engineer grew.
One junior Android engineer and a form that kept losing input
Here is the story used through the rest of this post. You’re a mid-level Android engineer on a banking app. A junior engineer joins the team. Call them Dana. Nobody assigns you as their mentor. You simply review most of their pull requests.
Dana’s screens work in testing. But two of their first three features lose the user’s typing. It happens when the app returns from the background. The cause is the same each time. Dana keeps form input only in a ViewModel. Android’s guide to saving UI states explains that ViewModels are destroyed when the system kills the app’s process. Saved state survives that case. Dana didn’t know the difference yet.
The first time, you fixed it for them in review. The second time, you noticed the pattern. That moment is where the mentoring story starts.
Switching from fixing to asking is the part interviewers can score
Orosz gives mentors direct advice. “Ask questions, offer alternatives, and hold back telling people what to do.” In the story, that change is concrete. You stopped writing the fix in review comments. Instead, you asked Dana one question on each new screen. What happens to this field if the system kills the app right now?
You also spent one hour pairing with Dana. You showed them how to make the system kill the app while it sits in the background. Dana saw their own form come back empty. After that, the question in review had a test behind it.
An interviewer can score this change. It shows you saw why the same comment wasn’t working. Then you adjusted how you helped.
The proof is what Dana did without you
Six weeks later, Dana reviewed a teammate’s pull request. They flagged the same state bug before you saw it. Dana also added a process-death check to the team’s pull request template. Then you stopped reviewing state handling on Dana’s screens line by line.
Each of those facts is checkable. A hiring manager could imagine asking Dana about them. A list of mentoring habits gives them nothing to ask about.
Sample answer to “tell me about a time you mentored someone”
I didn’t have a formal mentee. But I reviewed most of the pull requests from a junior engineer who joined our Android team. Two of their first three features lost the user’s input after the app came back from the background. Both times, the state lived only in a ViewModel. The system can destroy that when it kills the app.
The first time, I just put the fix in my review. When it happened again, I realized my comments weren’t teaching anything. They were fixing one screen. So I changed my approach. On every new screen, I asked one question in review. What happens to this field if the system kills the app now? I also paired with them for an hour. I showed them how to trigger process death on purpose. They watched their own form come back empty.
About six weeks later, they caught the same bug in another engineer’s pull request before I did. They also added a process-death check to our pull request template. After that, I stopped checking state handling on their screens line by line.
One thing didn’t land. Early on, I shared a reading list. They never opened it. The hands-on test worked far better for them. So now I start new teammates with one exercise, not a set of links.
We wrote this answer for this post as an illustration. Use your own teammate, problem and timeline. Keep every detail true.
Why the answer holds up when the interviewer digs
The first paragraph says “I didn’t have a formal mentee” before the interviewer can ask. That removes the doubt early. It then gives a narrow, technical problem. A narrow problem makes the later change easy to see.
The second paragraph holds the decision. “My comments weren’t teaching anything” shows you noticed your own method failing. The question and the pairing hour show what replaced it. Both follow Orosz’s coaching advice without naming it.
The third paragraph is the result, told as two things the junior did alone. Its last sentence is your own proof that the help worked. You stopped the line-by-line review because Dana no longer needed it.
The fourth paragraph admits something that failed. It keeps the story from sounding polished after the fact. It also answers a likely follow-up about what you’d do differently.
When the interviewer asks whether that was really mentoring
Some interviewers push back on informal stories. They may say it sounds as if you don’t have real mentoring experience. Don’t argue about the label. Restate the time span and the result in two sentences. For example: “It wasn’t a formal program. But it ran for about six weeks. They now catch that bug class in other people’s code.” Then offer a second, smaller example if you have one, like onboarding a new hire.
Other follow-ups target the edges of the story. “How did you know they were ready?” Answer with the pull request they caught on their own. “What would you do with a mentee who doesn’t improve?” Say what you’d try next. Then say when you’d bring in their manager. Story size may come up next. Our post on story scope and level shows how one story reads at junior, senior and staff. Sometimes helping a peer turns into a disagreement. For that case, see influence without authority when it ends in escalation.
If you’re interviewing for a senior role, keep two mentoring stories ready. Make one about an engineer’s skill and one about onboarding. Another round may ask a version of the same question. A second story means you won’t have to reuse the first.