When I was a junior software engineer I had an interview booked with a well-known stockbroker. When I landed it I was overjoyed. It meant working in London, good pay, benefits, and real training for the first time in my career.
As the date got closer I got less excited every day. I started crawling the job spec, the careers site and Glassdoor every thirty minutes, looking for anything that would give me a reason to cancel. I was about to phone the recruiter and give them an excuse they had probably heard ten times that week.
Then I worked out what was actually going on. It wasn’t me making that phone call, it was fear. Underneath it was anxiety about not being good enough and about being rejected on the back of a technical test. I used that to drive revision instead of cancellation, got the job, and it turned out to be one of the best opportunities of my career.
That was an interview for a job I had already been doing for years. The one you are preparing for now is harder, because you are interviewing for a job you have never done at all.
Every guide to engineering manager interview questions is written for people who have already managed. Tell me about a time you turned around an underperformer. Tell me how you handled a conflict between two of your reports. You have not turned around an underperformer. You have never had a report. So you read the list, mentally substitute a tech lead story, and hope it holds up.
It rarely does. An interviewer who has run a few of these panels can tell a story about owning people from a story about owning code.
They already know you have not done it
A company hiring a first-time engineering manager has already decided the risk is acceptable. It is on your CV and it was in the job description they wrote. Usually something in your record made them think you can move a team without needing authority to do it.
They take that risk because the upside is enormous. In “The Value of Bosses”, published in the Journal of Labor Economics, Lazear, Shaw and Stanton measured that swapping a boss in the bottom 10% of quality for one in the top 10% raises a team’s total output by more than adding an entire extra worker to a team of nine. A good manager is worth more than a headcount. That is what is on the table when they interview you.
The other half of the picture is less comfortable. The Chartered Management Institute, with YouGov, found that 82% of people entering management positions have had no formal management or leadership training. If you get this job, there is a very good chance you are about to join that 82%.
So the strongest answer to “have you managed people before” is no. Then the closest thing you have done, described accurately. Then the part you know you have not done.
Where candidates lose points is dressing up a mentoring relationship as management, and the points come off judgement rather than experience. If you tell a panel that mentoring a graduate for six months is basically the same as owning someone’s performance, salary band and career, you have told them you do not know what the job involves.
If you are joining my team as a first-time manager, I do not need you to have done it before. I need you to know what it costs.
”But I thought the point was to sell yourself”
Every piece of interview advice ever written tells you to present your strongest self, and I have just told you to volunteer a gap.
Selling yourself as a first-time manager means being credible about a job you have not done, and credibility breaks the moment you overclaim. A panel that catches one stretched story starts re-examining everything else you said, and you do not get to choose which parts they discount. The mentoring story you inflated costs you the underperformance answer that was actually good.
There is a version of this that costs more than the offer. Imply experience you have not got, get hired on it, and you arrive to a team who were told their new manager had done this before. Then your first difficult conversation goes badly in front of people who were told to expect competence.
“I have not managed before” is a fact. “I have not managed before, so I am probably not what you are looking for” is you doing the panel’s job for them, badly.
”Tell me about a time you gave difficult feedback”
You are going to reach for the code review story. The one where you pushed back on a design, held the line, and the code got better. It is the safest example you have, and it does not score.
Feedback in a code review costs you nothing. The forum exists for it and the worst case is a tense thread. What the panel wants is feedback that had a relationship on the other side of it. Someone senior to you, or someone you needed on side the following week, or someone who took it badly.
Say what you actually said, in the words you used. Not “I raised concerns around delivery,” the sentence you used. Then say how they reacted, including if it went wrong, and what the two of you were like a month later.
From my observations over fifteen years in this industry, when people hear the word feedback they become defensive or anxious before a single word of content arrives. That is the part panels want to hear you handle. Not the delivery technique, the reaction to it.
The answer that fails is the clean one, where you gave the feedback, they thanked you, and everything improved. Panels do not believe it. Even when it is true it tells them nothing about what you do when someone goes quiet on you, or argues, or agrees to your face and changes nothing.
If you want a structure to hang the answer on, SBI is the one worth knowing: situation, behaviour, impact. Where it was, what they actually did, and what happened as a result. It works because it strips out interpretation, and interpretation is the part people argue with. Nobody disputes that they interrupted three times in Tuesday’s design review. Plenty of people dispute that they are dismissive of junior engineers.
What SBI will not give you is the part after. The framework ends at impact, and the conversation does not. What you say in the silence that follows is the bit the panel is listening for, and no acronym covers it.
If you dig through the last three years and cannot find a single piece of feedback that cost you something, that is worth knowing before the interview rather than discovering during it.
Where to find your evidence when you have never managed
Most of the preparation for this interview is not rehearsing answers. It is going back through the last two years and finding the moments that count, because they exist and you have never catalogued them as management. This part is more encouraging than people expect.
Look for the times you owned an outcome nobody assigned to you. The migration everyone agreed was necessary and nobody picked up. The on-call rota you rewrote because it was quietly burning two people out. The graduate who was drowning and the eight weeks you spent on it instead of your own tickets.
Look for the times you changed a decision without the authority to make it. Talking a staff engineer out of their preferred approach, and keeping them on side afterwards, is closer to the real job than any 1-1 you have ever sat in.
The ones that matter most are the things that went badly. The project you let slip because you did not want to be the one to raise it. The person you knew was unhappy and did not ask about until their notice was in. Panels score self-awareness, and there is no way to demonstrate self-awareness with a story where you were right.
Write down eight of these before you apply anywhere. You will use four. The other four are there so you are not building an answer live in the room.
”How would you handle an underperforming engineer?”
Your answer will arrive too fast. Most candidates start solving in the first sentence: book a 1-1, set clear expectations, agree measurable goals, put a timeline on it, escalate to HR if nothing changes. It is a tidy pipeline and it signals that you think underperformance is a process to run.
The candidates who score spend their first thirty seconds on why. Is this person unable, unwilling, or unsupported? The three look identical on a sprint board and need completely different responses. Has anyone told them, in plain language, that there is a problem? Most underperformance sitting on a new manager’s desk has been running for a year while people made sympathetic noises and nobody said the words out loud.
Every single manager who has ever existed has looked for a reason to delay a difficult conversation and told themselves they would give it another two weeks. Every. Single. One. Saying that out loud in an interview, and then saying what you would do about it, is a better answer than any framework.
The part most candidates miss is what the team already knows. In my experience the engineers around that person have been carrying the hurdle for a while, and they have noticed that nobody is dealing with it. The cost of waiting is not only paid by the person underperforming.
You want to sound decisive, because decisive sounds like a manager. Decisive on incomplete information is precisely the instinct they are screening for.
”Two of your engineers cannot work together”
You will get some version of this, because it is the situation first-time managers handle worst.
The instinct is mediation. Get them in a room, hear both sides, find the middle. It is a reasonable instinct and it is usually the second step rather than the first.
Most problems on software engineering teams are people problems. They are rarely technical, even when they arrive dressed as something technical. The argument about the service boundary is very often an argument about who gets to make decisions, and if you mediate the technical dispute you will resolve nothing, because you will have settled the thing that was not the problem.
So the answer that scores starts with separate conversations rather than a joint one. What does each of them think this is actually about? How long has it been going on? It has almost always been going on for longer than you think, and both of them will describe an incident from months ago that never reached you.
Then the part candidates miss entirely. Conflict between two people stops being a two-person problem by about the second week. Everyone has quietly picked a side, meetings have got shorter, and work is being routed around the problem. Ask what the team’s version is, because the team has one.
You are not obliged to make them like each other. You are obliged to make the team work. Those are different targets, and saying so out loud is a strong answer.
”Tell me about a time you disagreed with your manager”
First-timers answer this as though loyalty is the thing being tested. You disagreed, you made your case, you committed to the decision, everyone moved on.
What the panel is checking is whether you will tell them things they do not want to hear once you report to one of them. A manager who only escalates good news is worse than no manager, because leadership finds out about the problem later and with fewer options.
Give them the disagreement you lost. What you argued, why you were overruled, and whether you still think you were right. “I was overruled, two years on I still think it was the wrong call, and here is what I did to make it work anyway” tells a panel more than any of your successes will.
The version that fails is the one where you disagreed and were then proved right. It is a humblebrag with a management theme.
The system design round is not about system design
You will get a technical round. You will assume it is there to check you can still think, and you will prepare accordingly.
They are watching what you do when someone in the room proposes something worse than your idea. Whether you take the pen. Whether you explain, efficiently and correctly, why they are wrong and then move on. Whether you notice the person who has not spoken and bring them in.
I am certainly not the best software engineer on my team, or any team I have managed. I am proud of that. It took me a while to get there, and getting there is most of what this round is testing.
Strong engineers lose engineering manager offers here by performing well. You solve it yourself, quickly and cleanly, and you have demonstrated the exact instinct the panel is worried about. The same instinct will hurt you in month one, when you are managing engineers who are better than you and your first move is to prove you can still keep up.
”How will you stay technical?”
This one is a trap, and almost everybody walks into it.
The instinct is to reassure them. You will keep picking up tickets. You will stay on the on-call rota. You will protect a day a week for coding. It sounds like commitment and it reads as somebody who has not accepted the job they are applying for.
What they are asking is whether you understand the difference between technical credibility and technical output. You need enough context to tell when an estimate is fantasy, when a design will not survive contact with scale, and when somebody is quietly gold-plating. None of that requires you to be writing production code.
The better answer is about mechanisms rather than hours. Reading pull requests without commenting unless it genuinely matters. Sitting in design reviews asking questions instead of answering them. Staying close enough to incidents to see the pattern without becoming the person who fixes them.
I do not need you to be the strongest engineer in the room. I need you to know enough to tell when the room is wrong.
There is a real cost here and it is worth naming, because the reassuring version of this answer is not true. Your technical depth will decay. Not to zero and not quickly, but it will go. If that prospect genuinely upsets you, it is far better to know it now than eighteen months in.
”Why do you want to be a manager?”
The answers that sink people here are all versions of the same thing. It is the natural next step. I want more impact. I have gone as far as I can go technically. Every one of those says management is a promotion, and any panel that has hired a regretful EM before is listening for it specifically.
The answer that works is usually smaller than the one you have rehearsed. A specific engineer whose career you affected. An onboarding you rewrote because you watched three people struggle through the same week. Somebody you talked out of resigning. Then the honest comparison: how that felt against shipping your own work, and why you want more of the first thing.
If the title is the real reason, the job will find that out within eighteen months, and the team will pay for the experiment before you do.
I should be straight with you here, because I cannot answer my own question the way I have just told you to. I first became an engineering manager at the start of covid. We were not hiring, the company needed the role filled, and I went in blind with no real idea what it entailed or whether I would be up to it. That is a far more familiar story than the considered vocation answer, and if it is closer to your situation than mine, you are in ordinary company.
Sarah Allen, a Lead Product Manager at Yelp, once told me that a leader can sometimes be a manager, but being a manager does not always mean being a leader. The panel is trying to work out which one they are hiring.
”What would your first 90 days look like?”
Almost every candidate answers this with a plan, and almost every plan is full of changes. Restructure the standup. Introduce a proper planning cadence. Fix the deployment pipeline everyone complains about. It is the answer of someone who has confused a management job with a consulting engagement.
There is a better spine for this answer, and it is older than any of us. In 1977 Tuckman, with Mary Ann Jensen, extended the four stages he had defined in 1965 into what we now know as the five stages of team development: forming, storming, norming, performing and adjourning.
The point for an interview is that you are inheriting a team already sitting at one of those stages, and you do not yet know which. A team in storming needs you to surface conflict that is being avoided. A team in norming needs you to embed what they have learned so it survives the next joiner. A team that looks like it is performing may have slid backwards without anyone naming it, because teams go backwards far more often than the model implies.
So the honest answer is that your first job is to find out where they are. Who you talk to, in what order, and what you want to understand before touching anything.
Then the exception. There is always one thing that would make you act in week one anyway, and it is usually a person being treated badly or a commitment that is going to be missed while everybody carefully avoids saying so.
Listening, then one small visible fix, then anything structural. Most of what goes wrong in a new manager’s first 90 days comes from getting that order backwards.
The gap you cannot close by preparing
Most of the interview will be hypothetical. What would you do if. How would you handle. Nothing in your career so far has made you practise those moments, because ICs are never in them. You have opinions about difficult conversations. You have never had one where the other person went silent and you had to decide what to do with the silence.
That gap shows up in the texture of your answers. Lived answers have specifics in them, awkward details, the bit where it did not go to plan. Prepared answers are smooth and slightly generic, and interviewers who have run a lot of these panels hear the difference without always being able to name it.
You can close some of it before you walk in. Play a first 90 days in the New Manager Simulator, make the calls, and watch where they land three months later. It takes about fifteen minutes and it hands you two or three moments you can talk about honestly, which is two or three more than most first-time candidates arrive with.
What to say when you do not know
Somewhere in the interview you will get a question you have no answer to. Not one you answer badly, one where you have genuinely got nothing.
The reflex is to build something plausible on the spot. Do not. Panels can hear it, and an invented answer costs you more than the gap it was covering, because now they are quietly wondering which of your other answers were assembled the same way.
Say you do not know. Then say what you would do about it: who you would ask, what you would want to understand first, and what you would be most worried about getting wrong.
If you tell me you do not know and then tell me how you would find out, I will trust the rest of your answers more, not less. That is a management skill being demonstrated live, which is more than most of your prepared answers will manage.
It is also honest rehearsal. Your first year as a manager is mostly questions you do not have answers to, asked by people who assume you do.
If you are interviewing to manage your current team
A lot of first-time engineering manager interviews are internal, and people treat the internal version as the easy one. It is the harder one.
The panel already knows your work, so nothing you say about your technical record moves the needle. Everything they are weighing is what happens to the relationships. Whether you can tell someone you have been to the pub with for three years that their performance is a problem. Whether you can rank them against each other in a calibration meeting in March. Whether you can be trusted with the things they told you in confidence when you were peers.
Raise it before they do, because they may never ask directly. There is at least one person on that team who will be difficult about you getting the job, and there is a fair chance they applied for it too. Say so, in general terms, and say how you plan to handle the first month with them.
Internal panels also listen for whether you are going to keep doing your old job. You own that service. You will know it better than anyone for at least a year, and every incident is going to pull you back towards it. Say what you are handing over, and to whom, by name.
The questions you ask are half the interview
Candidates ask about the tech stack and the release process, which tells the panel nothing.
Ask why the role is open. Whether the last manager left, was promoted, or whether the team has been running unmanaged for eight months. Ask how many reports, and the spread of levels, because six engineers between graduate and staff is a different job from three seniors. Ask what the team has missed in the last six months. Ask who left most recently, and why.
Ask who decides promotions and what your part in it actually is. I have spent years of my own career chasing promotions built on false promises from people who did not themselves know what the expectations of me were. You are about to be the person answering that question for six other people, so find out now whether you will be able to.
Ask what would make them consider this hire a mistake a year from now. The pause before they answer tells you more than the answer does.
You are finding out whether you are being handed a functioning team or a repair job with a title on top. Both are worth taking. Only one of them is the job you currently think you are accepting.
Closing Thoughts
There is no way I could have covered every question you will get, and the specific ones will vary wildly by company. I have written about the ones I have something real to say about, and about the mistakes I either made myself or watched from close enough to learn from.
What I did not expect when I went looking was the 82% figure. I knew training for new managers was bad. I did not know it was that bad, and it reframes the whole interview. You are not being assessed against a well-trained field. You are being assessed against people who will also be learning on the job, and the team is the one who pays for that learning.
Which is the part worth sitting with. Say no when the honest answer is no. Bring the feedback story that cost you something. Bring the disagreement you lost. Slow down on the underperformance question. Sit on your hands in the system design round.
None of that proves you can manage. It proves you know what managing is, which is the only thing anybody can prove before they have done it.
The interview is one stage of a longer run at it. If you are earlier than that and still working out how the promotion gets decided in the first place, start with how to become an engineering manager.
If you have been through one of these interviews recently, I would like to hear what they asked you. Send it over.
