Behavioural interviews · Module 07 of 12 · Level 2: The core questions

Leadership and influence

For most engineers, "leadership" questions aren't about managing people. They ask how you changed what others did when you couldn't tell them to: another team, a standard, a migration, a colleague's growth. This module shows the moves that work and how to tell them.

1. The idea

A good tour guide in a crowded city has no authority over the group. Nobody has to follow them. People follow because the guide clearly knows the way, explains why this street and not that one, waits for the slow walkers, and makes it easy to keep up. Most engineering leadership works the same way.

Leadership questions for engineers are rarely about managing people. They're about influence without authority:

"Tell me about a time you led a project or initiative."
"A time you convinced others to adopt your idea."
"A time you got another team to change something."
"A time you mentored or developed someone."

Strong answers show a sequence of moves, not a single meeting:

Understand first. What do the people you need care about? What does your idea cost them?
Show, with evidence. Data about the problem, or a prototype that removes their pain. Evidence persuades better than seniority.
Talk one to one before the big meeting (sometimes called pre-wiring). Objections improve the plan in private instead of blocking it in public.
Make it easy to say yes. Do the first migration yourself; write the guide; take on the risk.
Give the credit away. The first team to adopt becomes the example others follow.

Mentoring stories follow the same shape: what the person needed (not what you'd have wanted), what you did, and how they grew, in their terms.

2. How it works

An engineer with no authority over three other teams gets all three to adopt a shared deployment check. Watch the order of moves.

3. Try it yourself

Plan an influence campaign

Scenario: inconsistent logging across three teams makes every incident take an hour longer to debug. You've built a small shared logging library. None of the teams report to you. Pick four moves, in the order you'd make them.

4. What interviewers look for

Leadership is scored on how you moved people who didn't have to move, and how far the change reached.

Signal	Weak	Good	Strong
Method	"I told them to" or "my manager made them"	Explained the idea in a meeting	Understood their goals, showed evidence, pre-wired, made it easy
Reach	Your own team	One other team	Several teams, or the way the organisation works
Others' growth	Not mentioned	Helped someone once	Developed someone over time, with a visible change in what they can do
Credit	"I did it all"	Mentions the team	Credits the first adopters by name, and stepped back once it was theirs

5. A model answer

"Tell me about a time you influenced a team you didn't lead." An invented answer, shown part by part. Read it for the shape, then build your own from a true story.

SituationOur three product teams each wrote logs differently, so during incidents the on-call engineer spent the first hour working out which fields meant what. I was a backend engineer on one of them.

TaskI'd built a small shared logging library for my own team. I wanted the other two to adopt it, but I had no authority over them, and both were busy with their own roadmaps.

ActionI started by pulling the last six incident reviews: four said "logs inconsistent" as a delay, adding about 50 minutes each. I met each team's tech lead one to one and asked what would stop them adopting it. One worried about performance, so I benchmarked it and published the results; the other had no time, so I offered to migrate their noisiest service myself. That first migration went in within a week, and their on-call engineer posted in our engineering channel about how much faster the next incident was. I let that post do the persuading, and wrote a 20-minute migration guide.

ResultWithin two months all three teams used the library. The next five incidents averaged 35 minutes less to diagnose. The second team's lead now maintains the library with me.

LearningI'd go to the leads before building, not after: one of their requirements would have saved me a rewrite.

Why it scoresEach move is a real influence tactic: evidence first, one-to-one conversations, removing each team's specific objection, and letting a peer be the advocate. The result is measured, and the ownership is shared at the end.

6. Remember it

Memory hook: "Understand, show, make it easy"Find out what they care about, prove it with evidence, then remove the work of saying yes.

How this hook works: what “Understand, show, make it easy” means

What the slogan means, phrase by phrase

“Understand”: What do they want? What would your idea cost them? Ask before you pitch.
“show”: Evidence and prototypes persuade; titles and repetition don't.
“make it easy”: Do the first migration, write the guide, take the risk, and let the first adopter tell the story.

Why this picture fits: The tour guide has no authority, but knows the way, explains each turn, and waits for the slow walkers. People follow because it's the easiest good choice.

The story → the concept

The tour guide	Influence without authority
Knowing what the group wants to see	Understanding each team's goals
"This street avoids the crowds"	Data and prototypes
Waiting for the slow walkers	Removing each team's objection
The group recommending the tour	The first adopter persuading the rest

Watch it on an example

Understand: "What would stop you adopting this?" One lead says performance, the other says time.
Show: publish a benchmark; pull six incident reviews showing 50 lost minutes each.
Make it easy: migrate their noisiest service yourself; let their on-call engineer tell everyone.

The trap it saves you from

Mistaking a well-argued RFC for influence, then wondering why nobody adopted it.

It still works when…

You do have authority. Even then, people who were persuaded do better work than people who were told.

7. Common mistakes

"My manager told them to"That's your manager's influence, not yours. Choose a story where you did the persuading.

One big presentationInfluence rarely happens in one meeting. Show the one-to-one work before it.

Leadership = managingEngineers lead projects, standards, migrations and people's growth without managing anyone. Those are the stories to tell.

Mentoring as "I answered their questions"Show what they needed, what you did over time, and how they grew.

Taking all the creditInfluence stories land better when others carry the idea. Name them.

8. Practice exercise (25 minutes)

Find an influence story (5 min). A time someone you didn't manage changed what they did because of you.
List the moves (10 min). Write each move in order: understand, show, pre-wire, make it easy. Which did you skip?
Find the reach (5 min). How many people or teams did it change? Over how long?
Add a mentoring story (5 min). Someone you helped grow: what they needed, what you did, what they can do now.

9. Self-check quiz

Which move usually comes first when influencing a team you don't lead?

Understanding comes before persuading.

What does pre-wiring mean?

Objections improve the proposal in private instead of blocking it in public.

Which is the strongest evidence of influence?

Adoption plus a measured effect.

Why let the first adopter tell the story?

Social proof from a peer carries more weight than the author's enthusiasm.

10. Go deeper

Resource	Time	Why
Negotiating, presenting and leading (Software architecture, Module 03)	30 min	Influence techniques in depth, including pre-wiring and the architect elevator.
Hire and Develop the Best; Earn Trust (Amazon)	5 min	How one company describes developing others and earning trust.
Module 08: Ambiguity and trade-offs	Next	Deciding with half the facts.