Questions to Ask a Software Engineer Mentor
Questions for a mentee meeting a more senior engineer, covering how to set the relationship up, getting feedback on your actual code, what the next level requires, visibility, and what to bring to each session so the time is not spent on status updates.
20 questions, each with the reason to ask it · includes a conversation guide
The questions
Open any question to see why it works.
- 1
How do you want to use these sessions, and how often?
Settle the cadence in the first meeting, because a mentor who says to reach out whenever you need something is usually describing a relationship that will meet twice. Propose something specific, such as thirty minutes every fortnight, and let them negotiate it down.
- 2
What should I bring each time?
Mentors differ more than you expect here: some want a written agenda in advance, some want a link to a pull request, some want you to talk until something real surfaces. Asking directly saves the three sessions it otherwise takes to find out.
- 3
What did your own path look like from where I am to where you are?
Ask for the sequence rather than the lessons. Pay attention to whether their moves were internal promotions or job changes, because that shapes every piece of career advice they will give you afterwards without them noticing.
- 4
From what you have seen of my work, what is the one habit you would change first?
Asking for one thing rather than feedback in general forces a ranking, and the item they name first is the one that is most visible to other people. If they cannot name anything, they have not seen enough of your work yet, which is itself worth knowing.
- 5
Can we read one of my pull requests together and you tell me what you would have flagged?
This is the highest value hour available in the whole relationship, because generic advice about code quality does not survive contact with your actual code. Watch the order in which they read it, since senior engineers usually check the error paths and the tests before the logic.
- 6
When you review someone else's code, what makes you stop and leave a comment?
This surfaces their standards in a form you can apply tomorrow. Common answers are names that describe the wrong thing, error cases that silently pass, and tests that would still pass if the function were deleted.
- 7
How do you decide a design is good enough to start building?
Both over-designing and diving straight in are failure modes, and experienced engineers usually have a rough signal for the switch, such as knowing the failure modes and the rollback path. Ask what they do when they cannot get to that point.
- 8
How do you get into a codebase you have never seen before?
You want a technique you can copy, not encouragement. Strong answers are concrete: trace one request from entry point to database, read the tests before the source, find the deploy configuration, and change something small on purpose.
- 9
What is different about how someone one level above me works?
Ask for behaviour rather than rubric language. The real difference is almost always about the size of the problem handed to them and how much ambiguity they absorb before asking, not about technical depth.
- 10
What does a promotion here actually require, and who decides it?
The written rubric and the operating process are rarely the same thing. Ask who is in the room, what evidence they see, how far in advance a case has to be built, and whether your manager has ever taken someone through it.
- 11
How do senior people find out that my work is good?
Visibility has mechanics: design documents that circulate, demos, incident write-ups, being the person who answers in a shared channel. A mentor who has been in the promotion discussions can tell you which of those carries weight at your company and which is theatre.
- 12
What should I be saying no to?
Junior engineers accept everything and end up owning work that never compounds, such as permanent build babysitting or a one-off internal tool nobody else will touch. Someone who has watched your queue can name yours specifically, which is harder than it sounds to see from inside.
- 13
How do you handle disagreeing with a technical decision you think is wrong?
Ask for the actual sentence they would say and the point at which they would drop it. The second half matters more, because the engineers who damage their reputation are usually the ones who were right and could not stop saying so.
- 14
When you are stuck, how long do you sit with it before asking someone?
Team norms on this vary enormously and nobody writes them down, so new engineers either burn two days or interrupt hourly. Ask what a good request for help looks like in their team, word for word.
- 15
What have you got badly wrong, and what happened afterwards?
Every senior engineer has an outage, a rewrite that failed, or a bet on a technology that did not pay off. How freely they tell it, and whether the story ends in blame or in a changed process, tells you what the engineering culture is really like.
- 16
Which of my skills are worth going deep on, and which are good enough as they are?
This turns the depth versus breadth question into something actionable about you. A useful mentor will decline to say everything matters and will tell you which gap is currently costing you the most.
- 17
How do you keep learning now that nobody is teaching you?
Ask what they actually did in the last month rather than what they intend to do, which filters out the aspirational answer about books they have not opened. The honest answers are usually small: reading a specific system's source, rebuilding something badly on a weekend, or being the reviewer on unfamiliar code.
- 18
Do you think I should be heading toward staff engineer or management, and what makes you say that?
Asking early stops the drift where people take the first opening that appears. Notice whether the answer is grounded in things they have watched you do or in the path they took themselves, because the second is a much weaker signal.
- 19
Who else should I be talking to, and would you introduce me?
A mentor's network is the most transferable thing they own, and one warm introduction usually outlasts a year of advice. Make it easy by naming what you would want from the conversation so they can forward it in one line.
- 20
What do you get out of mentoring me, and how do I make this worth your time?
Asking makes the relationship two-directional instead of a favour you are drawing down. Common honest answers include seeing how the organisation looks from lower down, practice at explaining decisions, and evidence for their own promotion case.
Getting real value from an engineering mentor
Practical guidance for the conversation itself.
Running the relationship
Running the relationship
Propose the cadence yourself
Send a specific recurring slot rather than asking when suits them. Senior engineers have fragmented calendars, and the mentee who books the meeting is the one whose mentorship survives a busy quarter.
Bring a decision, not a status update
The worst use of the time is narrating what you shipped. Arrive with a choice you are stuck on, a review you disagreed with, or a piece of code you want torn apart, and the conversation gets useful in the first five minutes.
Close the loop out loud
Start each session by saying what you did with the last piece of advice, including when you ignored it and why. Mentors invest more in people who visibly act, and it also stops you collecting advice you never apply.
Between sessions
Between sessions
- Keep one running document of questions so you are not inventing an agenda on the walk to the meeting.
- Send code before the meeting, not during it. Reading takes longer than talking.
- Note the vocabulary they use for technical trade-offs and reuse it in your own design documents.
- Do the small introduction or reading they suggest within the week, while the context is still shared.
- Track your own questions that they could not answer, since those tell you what a second mentor should be good at.
Common ways engineering mentorship fizzles
Common ways engineering mentorship fizzles
- It is scheduled as needed, which in practice means never after the first month.
- The mentee only reports progress, so the mentor never sees a problem they can help with.
- The mentor is in the mentee's management chain, which quietly rules out the most useful topics.
- Sessions become therapy about a difficult team, with no technical content at all across months.
- Neither person ever says what the relationship is for, so both feel vaguely guilty and it lapses.