Engineering manager interview questions built around the conversations nobody wants
An engineering manager's job is a series of conversations most people avoid: telling someone their performance isn't good enough, telling a stakeholder the date is wrong, telling a strong engineer that the thing they want to build isn't the priority. Technical depth matters, but it isn't what separates candidates — almost every applicant has it. How they handle those three conversations is the job, and all three are visible in an interview.
What the job actually involves
An engineering manager is accountable for what a team delivers and for the people in it: hiring, one to ones, performance, growth, and the negotiation with product and leadership about what the team takes on. Most stop writing significant code fairly quickly, and the ones who don't usually struggle with the rest.
The role's difficulty is that its two halves pull apart. Delivery pressure pushes toward driving the team harder; the people half requires protecting them and being honest about capacity. Managers who only do one become either a bottleneck or a shield, and neither team ships well for long.
The questions, and what a good answer sounds like
Ask these as written. Each one is paired with what a strong answer sounds like, so two people rating the same candidate reach the same conclusion for the same reason.
1. Someone on your team is underperforming. Walk me through the first conversation.
A good answer: Early, specific, with examples and a clear statement that it is a problem, not a hint. Strong answers describe agreeing what better looks like and a date. Vague encouragement is the common answer and it is how someone ends up surprised at a review.
2. Your best engineer says they're bored and thinking about leaving.
A good answer: Takes it seriously immediately, finds out what specifically, and is honest about what they can and can't change. Promising a vague future project is the answer that loses them anyway, two months later.
3. Leadership commits your team to a date you know is wrong.
A good answer: Pushes back with the reasoning before committing, and if overruled, makes the risk visible in writing and manages scope. Accepting silently and then pressuring the team is the failure that damages both halves of the job.
4. Two engineers on your team cannot work together.
A good answer: Talks to both separately, finds whether it is a real disagreement or a personality clash, and intervenes not hoping. Strong answers accept that sometimes the answer is separating them.
5. How much code do you write, and how has that changed?
A good answer: An honest account with a reason. There is no single correct amount, but a manager who claims to code as much as before is either not managing or not being straight about it.
6. Someone reports a problem with a person more senior than them.
A good answer: Takes it seriously, protects the reporter, and doesn't resolve it by asking them to be more resilient. This is the question where a candidate's instincts about power show most clearly.
7. How do you know your team is doing well?
A good answer: A mix. Delivery, but also whether people are growing, whether hard things get raised, whether on-call is survivable. Managers who answer purely in velocity terms are measuring the easiest thing.
8. Tell me about someone you managed out.
A good answer: Handled with clarity and dignity, and a note about what they would do earlier. Managers who have never had to are usually early in the role, which is fine if they say so.
A scorecard you can rate against
Rate every candidate 1 to 4 on each row, and write the rating down before you watch the next one. Ratings drift badly when they're relative to whoever you just saw.
| Criterion | What a 4 looks like |
|---|---|
| Direct performance conversations | Specific, early, unmistakably clear it is a problem. A 2 hints and encourages. |
| Retention honesty | Acts immediately and is honest about limits. A 2 promises a vague future. |
| Protecting the team upward | Pushes back on a bad date and documents risk. A 2 accepts and passes the pressure down. |
| Handling power imbalance | Protects a junior reporter. A 2 counsels resilience. |
| Measuring more than velocity | Names growth, escalation culture and on-call load; a 2 answers only in delivery. |
How to run the screen
- This is among the strongest fits for a recorded round anywhere in tech. The job is conversations, so hearing someone deliver a difficult message is close to a work sample.
- Lead with the underperformance question. It is the conversation managers most commonly avoid, and the specificity in the answer tells you whether they have actually had it.
- Have the team meet them without you in the room. The people they would manage read this role differently than their peers do.
- Don't over-weight technical depth. Nearly every candidate has enough. Almost none of them are separated by it.
- Ask a live scenario where you play the unhappy report. How someone handles that in real time is not testable any other way.
Running this on a large applicant pool is where it gets expensive. VoxScreen sends these questions as a single link, transcribes and scores every answer against criteria you set, and hands back a ranked list. Free for 50 candidates a month, no card.
Common hiring mistakes for this role
- Interviewing engineering managers like senior engineers. It selects for technical depth, which doesn't distinguish candidates, and misses the conversations that do.
- Not asking about underperformance directly. Avoiding that conversation is the most common managerial failure and the most expensive to the rest of the team.
- Skipping the team meeting. Peers and leadership read a manager candidate very differently from the people who would report to them.
- Rewarding the manager who still codes most. It usually signals a team being under-managed instead of a technically strong one.
- Treating velocity as the health metric. It is the easiest thing to measure and the easiest to improve in ways that cost you later.
Common questions
What should I ask an engineering manager in an interview?
Ask how they open a conversation with someone underperforming, what they do when their best engineer says they're bored, and what happens when leadership commits their team to a date they know is wrong. Those three are the conversations the job is actually made of, and the specificity in the answers tells you whether the candidate has had them.
How much should an engineering manager still code?
There's no single right answer, and the question is diagnostic instead of prescriptive. What matters is whether the candidate has a reason for their answer. A manager who claims to write as much code as before is usually either not doing the management work or not being straight about it, and both are worth knowing.
Should the team interview their prospective manager?
Yes, and without you in the room. The people who would report to a manager read the role completely differently from peers and leadership — they notice whether someone listens, whether they talk about previous reports respectfully, and whether the answers change when nobody senior is present. It is the highest-signal round available.
Is a recorded interview useful for management roles?
It is one of the strongest fits in tech hiring. The job is conversations — performance feedback, pushing back on a date, retaining someone who is drifting — so hearing a candidate deliver a difficult message is close to a work sample instead of a proxy. Follow it with a live scenario where you play the unhappy report, which nothing recorded can replace.