Leadership questions are asked at every level, not only of managers. “Tell me about a time you led without authority.” “Tell me about someone you mentored.” “Tell me about a time you gave difficult feedback.” “Tell me about feedback you received and what you did with it.” For a mid-level engineer these questions are how a company decides whether you are ready for senior; for a senior engineer, they are often the deciding round.
This post covers what each of the four is really asking, the skeleton for each, one real example of leading through teaching, and how to answer honestly when you have not had the formal role the question seems to assume.
Leadership without authority
This is the most common form, and it is asking: can you get people to move in a direction when you cannot tell them to? Engineers lead without authority all the time — driving a migration across teams, setting a standard, getting a reluctant group to adopt a tool — and rarely think of it as leadership.
The answers that score well show three things: you made the case with evidence the other people cared about (their pain, not your preference), you made the right thing easy to do (a script, a template, a migration guide), and you brought people along rather than announcing a decision. The weakest answers are about persuading people by being right.
LEADING WITHOUT AUTHORITY
THE DIRECTION what needed to change, across people you didn't manage
WHY THEY'D CARE the problem in THEIR terms, with evidence
MAKING IT EASY what you built / wrote so adopting it cost them little
BRINGING PEOPLE who you convinced first, how resistance was handled
RESULT how far it spread, and how you knowThe “making it easy” line is where engineers have a natural advantage. A standard nobody follows becomes a standard everyone follows when it comes with a linter rule, a template repository or a one-command migration. Showing that you led by removing friction is a very strong signal.
A real example: leading by teaching
Teaching is a form of leadership that is easy to overlook in your own history. Here is a real one, useful for “tell me about a time you had an impact beyond your own work” and as a mentoring story at scale:
Situation. I started lovemesomecoding.com to help aspiring developers understand what they actually need to know to start a career in programming, because most of what I found online was either too shallow to use or too disconnected from real work.
Action. I've kept it going for years, and recently rebuilt how the tutorials are made. The newer series take their examples from real, running applications rather than toy snippets, and automated checks prove the code on the page matches code that actually runs. When one of those pages says something is faster, the number has to have been measured. The point was that a beginner who copies an example should get something that works, and that what they learn should transfer to a real codebase.
Result. The site now holds close to a thousand tutorials across Java, Spring Boot, Python, databases, front-end frameworks, mobile, cloud and system design, all free.
Learning. The way to help people at scale is to raise the floor of what they're given: examples that are true, so nobody learns a wrong thing from you.
Notice what this story shows that a team-lead story might not: a standard set and enforced over a long period, for an audience you never meet. It answers “what do you care about?” as well as “how do you lead?”, which is why it is worth having in the bank even if you also have a classic team story.
Mentoring
“Tell me about someone you mentored” is asking whether you can make another person better, which is different from being good yourself. The trap is telling a story where you solved the mentee's problems for them. That is helping, not mentoring.
MENTORING
WHO AND WHERE their level, what they were struggling with
WHAT YOU NOTICED the underlying gap (often not the one they asked about)
WHAT YOU DID questions you asked, things you let them try, how you reviewed
WHAT YOU DIDN'T the fix you could have done for them, and didn't
THEIR RESULT what THEY could do afterwards that they couldn't beforeThe result must be about them, not you. “Three months later she was reviewing other people's database migrations” is a mentoring result; “we shipped the feature” is not.
Giving difficult feedback
The interviewer is checking that you will give hard feedback at all — many people avoid it — and that you can do it without damaging the person or the relationship. The pattern that works:
- Privately, and soon. Not in a group code review, and not three months later in a performance cycle.
- About behaviour and impact, not character. “The last two PRs went in without tests, and one of them broke checkout on Friday”, not “you're careless”.
- Curious before conclusive. Ask what was going on. There is often a reason — a deadline pressure you did not know about — that changes the conversation.
- A clear ask, and a follow-up. What should change, and when you will look at it again together.
End with what happened: did the behaviour change, and how is the relationship? If the honest answer is that it did not change and you escalated, that can still be a strong story, provided you can show you gave the person a fair, clear chance first.
Receiving feedback
“Tell me about feedback you received” tests the mirror image: can you hear criticism without defending yourself, and did you change? The best answers pick feedback that stung and was right, show a brief honest reaction, and then spend most of the time on the change.
One rich and increasingly common source of feedback stories is code review, including review of your work by automated tools and by AI reviewers. A story about a reviewer catching something you were sure was fine, and the habit you changed as a result, is perfectly good material, as long as the change is concrete: “I now write the failing test before the fix”, not “I'm more open to feedback”.
RECEIVING FEEDBACK
THE FEEDBACK what was said, by whom (role), about what
FIRST REACTION honest and brief - "my first instinct was to defend it"
WHY IT WAS RIGHT what you saw once you looked properly
WHAT YOU CHANGED a specific habit, check or behaviour
EVIDENCE how you know the change stuckWhen you have not had the formal role
If you have never managed anyone, do not pretend, and do not apologise either. Say so in one sentence and pivot to the leadership you have done: “I haven't managed people formally. The closest I've come is ___ , and here's what happened.” Then tell a leadership-without-authority or mentoring story with the same structure you would use for management.
Interviewers asking a leadership question of an individual contributor are almost always looking for exactly that kind of story. The candidate who says “I've never led anything” has usually led plenty and filed it under something else: owning an incident, onboarding a new hire, writing the guide everyone uses. Go back to your story bank and look again.
What to take from this
- Leadership questions are asked at every level; most of them mean leadership without authority.
- Lead with evidence people care about and by making the right thing easy.
- Mentoring results are about the other person's growth, not your output.
- Give hard feedback privately, soon, about behaviour, with a clear ask and a follow-up.
- For received feedback, pick one that stung and was right, and show a concrete change.
- Never claim a role you have not had. Pivot honestly to the leadership you have done.
Next, and last: why us, why leave, and the questions you should ask.