Questions to Ask Engineering Manager
Questions for an engineer meeting an engineering manager, in an interview loop or in an early one to one: how work reaches the team, what happens when plans slip, how on call and code review actually run, and how promotion decisions get made.
The questions
Open any question for the note
What did your last week look like, and how much of it was with people rather than code?
Why ask it
A concrete week tells you whether they are a working manager, a full-time people manager, or a tech lead with a title. It also shows how much of their attention any one report can realistically get.
How many engineers do you manage, and how many did you hire yourself?
Why ask it
A manager who inherited an entire team is in a different position from one who built it, particularly around trust and around who they defend in a reorganisation. Ten or more reports usually means one to ones get cancelled.
Why is this role open?
Why ask it
Growth, backfill and a role created after someone quit produce very different first six months. If the answer is backfill, ask what the previous person's biggest frustration was, which most managers will answer honestly.
What is the team working on this quarter, and who decided that?
Why ask it
The second half is the real question. Teams that set their own quarter behave differently from teams handed a list, and both exist inside the same company, often on adjacent floors.
How does work reach the team day to day?
Why ask it
Look for one intake path or several: a roadmap, tickets from support, direct messages from executives. Multiple uncontrolled inlets is the most common reason engineers feel busy and unproductive at the same time.
What happens when an estimate slips?
Why ask it
Every plan slips, so the interesting part is the response: rescoping, adding people, longer hours, a conversation with a stakeholder. Ask for the most recent example rather than the general policy.
When did you last choose to fix old code instead of shipping something new, and how did you argue for it?
Why ask it
Anyone can say they take technical health seriously. A specific instance shows whether they can win that argument with product, and how much of the team's time it was actually worth.
Who is on call, how often does it come round, and what was the last incident?
Why ask it
The rota frequency and the last real page tell you more about the system's health than any architecture diagram. Ask whether managers are on the rota, and whether anyone is paid or given time back for nights.
How does code review work here, and how long does a change usually wait?
Why ask it
Review latency shapes daily life more than any tool choice. Look for a norm with a number attached, and ask what happens when a reviewer disagrees and nobody is available to break the tie.
How long does a one-line change take to reach production?
Why ask it
One of the most revealing questions you can ask, because the answer encodes the build system, the test suite, the release process and the amount of approval theatre. Days rather than minutes is worth understanding before you accept.
What do you do when two engineers disagree about a design?
Why ask it
Listen for a mechanism, a written proposal, a decision owner, a time limit, rather than a belief that good people work it out. Teams without a tiebreaker tend to relitigate the same decision for months.
How do promotions work, and who actually decides?
Why ask it
You want to know whether there is a written ladder, how often the committee meets, and how much of it rests on your manager's advocacy. Vague answers usually mean promotion depends on being noticed rather than on criteria.
Who on your team was promoted most recently, and what did it take?
Why ask it
The concrete case exposes the real bar, and whether anyone has cleared it lately. If nobody has been promoted in two years, that is worth knowing regardless of how the process is described.
How do you find out when someone is struggling, and what do you do first?
Why ask it
Managers learn this through one to ones, through metrics, or through a complaint from someone else, and which one they name matters. The first move also matters: a quiet conversation and support is a different manager from one whose first step is a formal plan.
What does a bad quarter look like for this team, and how would I know we were in one?
Why ask it
Invites honesty about failure in a way that most interview questions do not. A manager who can describe the last bad quarter plainly is likely to tell you the truth when you work for them.
How do you protect the team from interruptions and last-minute requests?
Why ask it
Ask what they have actually said no to recently. A manager who cannot name an example is probably passing requests straight through, which is what makes a roadmap meaningless by week three.
How do you work with product and design: are you in the room when scope is set?
Why ask it
Engineering managers who join after the commitment has been made spend their year absorbing the difference. The answer tells you whether feasibility gets discussed before or after a date is promised.
What feedback from your reports has changed how you manage?
Why ask it
A specific answer shows they collect feedback and act on it. A generic one, or a claim that nobody has raised anything, suggests their reports do not think saying something would help.
How would you describe your role in the first month of someone joining this team?
Why ask it
Onboarding is where managers reveal how much structure exists: a buddy, a first task chosen deliberately, documentation that works. Being told you will figure it out is a signal about the next year, not just the first month.
What would you change about how this team works if you had the authority?
Why ask it
Answers here separate managers who see clearly from managers repeating a recruiting script. It also tells you which constraints come from above them, which are the ones you would inherit and could not fix.
Six months in, what would make you think hiring me was the right call?
Why ask it
Turns the conversation into an explicit description of success, which you can hold on to later. Watch for whether the answer is about shipped work, unblocking others, or simply being easy to have around.
Getting a straight answer from a manager
Practical guidance for the conversation itself
How to ask
- Ask for the most recent example rather than the general approach. Anyone can describe a philosophy of code review; only someone living it can tell you how long yesterday's pull request waited.
- Prefer questions with a number in the answer: reports, on-call frequency, review latency, deploys per week. Numbers are hard to improvise and easy to compare across teams.
- Save the hardest question for last. Managers relax over the course of a conversation, and the answer at minute forty is usually more candid than the one at minute five.
Reading the answers
- A manager who names a real failure and what it cost is more trustworthy than one whose examples all end well. The second kind is either new to the role or managing your impression.
- Watch what they blame. Consistent blame on other teams, on the previous manager, on the last regime tells you how a difficult quarter with you in it would be narrated.
- Notice whether they ask you anything about how you like to work. Managers who never ask tend to run everyone the same way.
Checking what you were told
- Ask to speak to one of their reports without them present, and ask that person about on call, review times and the last person who left. Contradictions matter more than either answer alone.
- If the process sounds unusually mature, ask who wrote it down and where it lives. Documentation that nobody can point to usually does not exist.
- In a first one to one after joining, ask the same three questions again. Comparing the interview answers with the ones you get from inside is the fastest way to calibrate a new manager.