Leadership and influence

Updated October 7, 2026 · By the Devana Team

Leadership questions for engineers are rarely about managing people. They ask how you moved others without authority: getting a team to adopt a practice, aligning another team on a dependency, mentoring someone, or bringing in a technology nobody knew. The interviewer wants the mechanism of your influence (evidence, listening, small wins) rather than a job title.

Theme 5 of 6 in behavioral themes

What the question is testing

Senior engineers multiply a team's output. The question tests whether you can see a change worth making, bring people with you instead of around you, and make it last after you stop pushing. How you handled the people who were not convinced matters more than the people who were.

How to structure the answer

  • Situation: what needed to change and why it was not changing.
  • Task: your role, and that you had no authority to order it.
  • Action: how you built the case (data, a prototype, a pilot), who you talked to first, and how you handled objections.
  • Result: what changed, how widely, and whether it lasted.
  • Learning: what you now do when you need others to change something.

An example answer

Question: "Tell me about a time you changed how your team works." The details are invented to show the shape.

Situation  Code reviews on our team often waited two days, which slowed
           every release.
Task       I was a mid-level engineer with no say over the process, but
           I thought we could halve the wait.
Action     I pulled three months of review times to show where they
           stalled, suggested a two-week trial of smaller pull requests
           and a daily review slot, and paired with the two most
           skeptical reviewers on their first small reviews.
Result     The median wait fell from two days to five hours during the
           trial, and the team voted to keep it.
Learning   A short, measured trial persuades people more than an
           argument about the right way to work.

Common mistakes

  • Describing authority ("I told the team to...") instead of influence.
  • Skipping the people who disagreed, which is the interesting part.
  • A change that faded as soon as you stopped pushing it.
  • Mentoring stories with no change in the person mentored.
  • Taking credit for a whole team's effort.

How to say it out loud

Name your lever explicitly: "I didn't have the authority to change the process, so I used the data and a two-week trial." Then describe one conversation with someone who was unconvinced and what moved them.

Structure and pacing are delivery metrics in Devana's behavioral rubric, and influence stories tend to sprawl because many people were involved. Keep it to the two or three people who mattered, and finish with a result someone could check.

Practice questions

These come from Devana's question bank, in the order to try them. Each one starts a voice mock interview with Josh, Devana's AI interviewer, on that question, so you practice explaining the story out loud as well as getting it right.

  • Changing how your team works

    mediumMicrosoft · Changing a practice without authority.

    Practice
  • Mentoring someone specific

    mediumGoogle · Influence measured by someone else's growth.

    Practice
  • A cross-team dependency that slipped

    mediumMeta · Aligning a team you do not work in.

    Practice
  • Choosing a technology the team did not know

    mediumDiscord · Bringing people along on an unfamiliar choice.

    Practice

Prove it in a mock interview

A 15-minute mock interview on a question that is not on the practice list, scored out of 100. Score 70 or more and leadership and influence is marked proven on your roadmap. It counts as one of your interviews: the Free plan has 3 a month, no card needed.