Engineering Manager Interview Questions

"I was a backend engineer for about six years. As a senior I started doing the parts nobody owned: onboarding new hires, running design reviews, untangling priorities with product. I noticed I got more out of a new hire shipping their first big feature than out of shipping one myself. When my manager left, I asked to take the team rather than wait for someone external. The first year was humbling, mostly learning to stop fixing things myself. Since then I've led two teams, and the thing I'm proudest of is that three people I hired are now leading work on their own. That's why I stay in management: the team's output is my output now."

"My core belief is that my job is to make the team better at deciding and shipping without me. Day to day that looks like clear goals and context, then getting out of the way. My team would see weekly one-on-ones that are their meeting, not a status update. They'd see me write down why we picked a priority so nobody has to guess. And they'd see me give feedback quickly, in private, while it's still useful. The trade-off is that handing out ownership means some things get done differently from how I'd do them, and sometimes a bit slower at first. I accept that, because a team that only works when the manager is in the room doesn't scale."

"In the first month I'd mostly listen. I'd hold a long one-on-one with every engineer and ask what's working, what's frustrating and what they'd change if they were me. I'd meet the product manager, my own manager and the teams we depend on. I'd read the last few incident reviews, sit in on on-call handovers and try to ship one small change myself so I understand the build and deploy path. By the end I'd pick one thing the team keeps complaining about and fix it, because that earns more trust than any speech. What I'd avoid is arriving with a new process from my last job. Things usually look odd for a reason, and I'd want to know the reason first."

"I had a mid-level engineer whose pull requests kept stalling for days and whose estimates slipped every sprint. Before assuming anything, I raised it in our one-on-one with two specific examples and asked what was going on. It turned out part of it was a family situation, and part was that he'd never worked with our event system and was too embarrassed to ask. So we did two things: a few weeks of lighter load, and pairing with a senior on the event work. I wrote down what good looked like for the next six weeks and we checked in weekly. He got there on the technical side and is still on the team. I've had another case that didn't recover, and there I moved to a formal plan with HR and it ended in a respectful exit."

"I had a senior engineer who was the best debugger on the team but had never led a project. She wanted to, and the gap was mostly planning and pulling other people in instead of doing it all herself. I gave her the lead on a payments migration that needed three engineers for a quarter. I asked her to write the plan and run the kickoff, and I met with her weekly just on leading, not on the code. The key moment was week three, when she was about to take the hardest ticket herself. I asked her who else could grow by taking it. She gave it to a mid-level engineer and paired with him instead. The migration shipped, and the next quarter she was formally a tech lead."

"When I was promoted, I was managing five people I'd worked beside for two years, and one of them had also applied for the role. In my first week I had a one-on-one with each person and said plainly that it was a bit strange for me too, and asked what they wanted from a manager. With the colleague who'd applied, I asked what he'd hoped to do in the role and gave him ownership of our architecture reviews, which was the part he cared most about. I also stopped joining the team's complaining about leadership, which was harder than it sounds. The first real test was giving critical feedback to a friend. I did it the same way I would for anyone, and she told me later that's when she took the change seriously."

"First I'd thank them for being direct and ask what's driving it. Sometimes it's really about pay, sometimes about feeling overlooked, sometimes there's already an offer. Then I'd be honest: against our senior level, here's where you're already there, and here are the two gaps, for example leading a project across teams and mentoring others, with specific moments where I saw those gaps. I'd propose a plan: the next cross-team project, a check-in every month, and a clear view of what the case would look like next cycle. I wouldn't promise the promotion, and I wouldn't push one through just to keep them. That's unfair to everyone else and sets them up to struggle. If they still choose to leave, I'd tell them I understand and part on good terms."

"I hold them weekly, usually thirty minutes, and I try hard never to cancel, because cancelling tells people they're the first thing to go. It's their meeting: we keep a shared doc and their topics go first. I avoid project status, since that belongs in standup or the tracker. My own questions rotate: what's frustrating you right now, what's one thing I could do better, what are you learning. Every few weeks I make it a career conversation about where they want to be in a year. The part that makes them useful is follow-through. If I say I'll chase a decision or raise their name for a project, it goes in the doc and I report back the next week. Without that, people stop bringing real problems."

"A formal plan should never be the first time someone hears there's a problem. Before it, there should be weeks of specific feedback in one-on-ones, written down, with the person knowing clearly that their performance is below the bar. If they're surprised, I've failed. When a plan is needed, I involve HR early, because the rules and the process differ by company and by country. The plan itself has a few specific goals tied to the level, like taking a medium-sized feature from design to production with tests, within an agreed number of weeks, not vague things like show more ownership. I give real support, a mentor or pairing, and check in weekly with written notes. A fair plan is one the person could genuinely pass, and I want them to."

"One of the best-liked engineers on my team kept marking work as done when it wasn't: merged without tests, or a feature flag left off in half the regions. Twice that month, whoever was on call got paged for it at night. It was hard because he was popular and clearly working long hours. I told him privately: three times this month you marked a task done that wasn't finished, the search change had no tests and the rollout stopped halfway, and twice someone else was woken up for it. I need done to mean tested and fully rolled out. He was embarrassed and said deadlines made him rush. I told him I'd rather hear a date is at risk than get half-finished work, and we wrote down what done means for the team. He started posting rollout status when he finished, and there were no repeats that quarter."

"I'd start by collecting real examples: a few review comments and what the juniors actually told me, with their permission. Then I'd talk to the engineer privately. I'd say something like, your reviews catch real problems and I value that, but comments like these are making people afraid to open pull requests, which slows the whole team down more than any bug you catch. At your level, making others better is part of the job. I'd be specific about what good looks like: explain the why, ask questions, and move big debates to a call. Then I'd watch the next few weeks of reviews. If nothing changes, it becomes part of their performance review, because output that costs the rest of the team isn't really high performance."

"The main thing is to give it soon and make it specific. I use a simple shape: the situation, what the person actually did, and the impact it had. So instead of saying your communication needs work, I'd say, in yesterday's planning meeting you committed to the Friday date without checking with the two people doing the work, and they felt blindsided. Then I ask how they saw it, because sometimes I've missed something. We agree what they'll do next time. I do the same with positive feedback, being specific about what was good so they repeat it. Critical feedback goes in private; praise can be public if they're comfortable with that. Nothing in a performance review should be the first time someone hears it."

"I hired a senior engineer who was superb in the technical rounds. Within two months it was clear he struggled to work with others: he rewrote teammates' code without telling them and dismissed questions in chat. I gave direct feedback early and we tried a clear plan, but after a few months it wasn't improving and we parted ways. When I looked back, our loop tested coding and design hard, but every signal about collaboration came from one casual chat that nobody scored. So I added a structured round where the candidate reviews a real pull request with one of our engineers, scored against written criteria. It's caught two people since who were strong alone but rough with others."

"I'd start by writing down what this person needs to do well in their first six months, say, own a service, debug production issues, and review others' code. Then I'd map rounds to that. A short screen on their past work, a practical coding exercise close to our real code rather than a puzzle, a design discussion scaled to mid-level, and a round where they review a pull request with one of our engineers, to see how they give feedback. Every round gets written criteria and a score, and interviewers submit feedback before we talk, so the loudest voice doesn't decide. I'd keep the total time reasonable, and I'd make sure every candidate hears back quickly, because a slow process loses good people."

"First I'd ask what the extra people are for, because that decides the shape. If it's really two separate goals, I'd plan for two teams of about five from the start rather than one team of ten, since standups and planning stop working well at that size. Then I'd hire in waves, two or three at a time, and get each group productive before the next arrives, because every hire costs the current team time in interviews and onboarding. I'd tell product up front that delivery will dip for a while before it rises. Onboarding would be a real plan: a named buddy, a small change in production in the first week or two, and clear goals for the first ninety days. And I'd start growing a tech lead for the second team early, so the split doesn't depend on me alone."

"We committed to a new reporting feature in eight weeks and shipped in thirteen. The real problem was that we estimated the parts we understood and waved at the data migration as one line item. It took five weeks on its own. My part was that I accepted the estimate without asking what we were least sure about. I did tell product and our sales lead as soon as the migration spiked, about four weeks in, with a new date and a smaller option we could ship sooner. They took the smaller option for one customer. Since then, every plan we make names its riskiest unknown, and we spend the first week on a spike for that before we give a date."

"I'd sit down with the product manager privately first, not in front of the team. I'd bring the estimate and what's driving it, and ask what the customer actually needs by that date. Very often it's one part of the feature, not all of it. Then I'd lay out real options: a smaller version by their date, the full version by a later one, or a trade where we pause something else. What I won't offer is quietly asking the team to work weekends for a month, because that just moves the cost somewhere hidden. Once we agree, product tells the customer, with me there if it helps. Afterwards I'd agree a simple rule with product that no external date goes out without a quick check with engineering."

"The engineers who'll do the work estimate it, not me. We break a project into pieces of a few days each, and for anything bigger we give a range rather than a single number. Every plan lists its riskiest unknowns, and we spend the first days on those, because that's where estimates are usually wrong. For outside dates, I share a date we're fairly confident in, not the best case. When an estimate turns out badly wrong, I treat it as information, not blame. I tell stakeholders as soon as we know, with a new date or a scope choice. Afterwards we look at why: was it hidden work, interruptions, or too much optimism? We adjust our next plan based on that."

"A strong mid-level engineer left for a senior role elsewhere. In the exit chat she said she'd felt stuck on maintenance work for a year. The honest answer is I probably could have kept her. The signs were there: her one-on-ones had become short and she'd stopped asking about the roadmap. I read that as her being settled, when she was actually checking out. I'd also kept her on the legacy service because she was the one who knew it, which is a classic trap. Since then I ask every engineer every quarter what they want to be doing in a year, I rotate ownership of the painful systems, and when someone goes quiet I ask directly instead of assuming things are fine."

"I'd raise it in our next one-on-one, or sooner if it looked serious. I'd say something like, I've noticed you're online late most nights and you seem more stretched than usual, and I wanted to check how you're doing. Then mostly listen. If it's workload, that's on me to fix, not them, so I'd look at what I can take away: move a ticket to someone else, push a date, or cover their on-call week. If it's pressure they put on themselves, I'd be clear that I don't expect late nights and I'd model that myself. If it's something personal, I'd point them to the support we have and give flexibility. And I'd ask myself whether others are showing the same signs, because one tired person is sometimes a sign of a team-wide problem."

"I look at three kinds of signal together. First, outcomes: are we actually moving the goals we agreed with product, like adoption of a feature or fewer support tickets? Second, delivery flow, the four measures people often call the DORA metrics: how often we deploy, how long a change takes from commit to production, how often a change causes a failure, and how quickly we recover. Those tell me whether the system around the team is healthy. Third, people signals: what I hear in one-on-ones, a short team survey every quarter, out-of-hours pages, and whether people are leaving. I only look at trends at the team level. The moment you use a metric to rank individuals, people optimise the number instead of the work, so lines of code or ticket counts tell me almost nothing."

"I care most about ownership, candour and sustainable pace. If you visited for a week, you'd see engineers talking directly to product and to customers, not waiting for me to pass messages. You'd see code reviews that ask questions and explain the why. You'd see someone say I don't know in a meeting, or admit they broke something, without anyone flinching, and you'd see me do it too. And you'd see people logging off at a normal hour, because I watch on-call load and push back on dates that need heroics. I protect it by acting quickly when someone works against it, even a strong performer, because culture is really set by what the manager tolerates."

"Mostly it comes from how I behave, not what I say. I admit my own mistakes out loud, like saying in standup that I misread a requirement and it cost us two days. When someone tells me they broke something, the first thing I say is thanks for flagging it quickly, and then we fix it. If I sigh or look annoyed even once, people remember. I also ask the obvious questions in meetings myself, so juniors see that not knowing is normal. And in our incident reviews we talk about what made a mistake easy to make, not who made it. Over time you can see it working when people start raising problems early, while they're still small."

"First I'd talk to their manager directly and try to understand what's ahead of us on their list. Often they have a good reason I just can't see. Then I'd offer options. Could one of my engineers build the endpoint in their codebase with their review? Is there a smaller version that unblocks us? If none of that works and our goals really conflict, it's not a fight between two managers. It's a priority question for whoever owns both roadmaps. I'd suggest we write one short note together with both sides and the cost of each choice, and take it up jointly. Meanwhile I'd tell my product manager that the date is at risk, so nobody is surprised later."

"The best ones I've had felt like a partnership with a clear split. The product manager owns what we build and why, I own how we build it, how long it takes and the health of the team, and we both own whether it actually worked for users. We meet every week just the two of us to go over priorities, risks and capacity, so nothing surprises either of us in front of the team. If we disagree, we sort it out privately and then present one plan. I also want engineering in the room early. My engineers often spot a cheaper way to get most of the value, or a technical idea product hadn't thought of. What I try to avoid is a relationship where product writes tickets and we just estimate them."

"First I'd join the call and ask the on-call engineer for a one-minute summary: what's broken, since when, and what's changed recently. If nobody's running the incident, I'd either take that role or hand it to someone experienced, and I'd make sure one person is posting updates so the engineers can focus. Then I'd push toward stopping the bleeding before understanding it: was there a deploy we can roll back, a feature flag we can turn off, a region we can fail away from? If the on-call is stuck on a system they don't know, I'd page its owner rather than let them struggle alone. I'd set a rhythm, say an update every fifteen or twenty minutes. What I wouldn't do is grab the keyboard myself and stop coordinating."

"Within a few days, I'd get the people involved to build a timeline together: what happened, what they saw, and what they did. The key question isn't who made the mistake, it's why that action made sense at the time. If an engineer ran the wrong command, why did the tooling let them, and why did it look right? That's what blameless means to me. It's not avoiding accountability, it's looking for the fix that stops the next person making the same mistake. Then we pick a small number of actions that change the system, like a safer deploy step, a missing alert or a test, each with one owner and a date. I track those actions in our planning, because a review whose actions never get done is just a story."

"A week of debate usually means nobody knows who decides. I'd ask both of them to write a one-page summary of their option against the same criteria, things like operating cost, how long it takes, and how hard it would be to undo. Often, once it's side by side, the gap is smaller than the argument suggested. I'd also ask how reversible this is. If we could switch in a month, we should just pick one and move. Then I'd name a decider, usually the tech lead or me, and a date, often two or three days out. Once decided, I'd ask the person who lost to help make it work and record their concern in the decision note, so if they turn out to be right, we notice early."

"I don't treat debt as a separate wish list. I keep a short, ranked list of the debt that actually hurts us, and for each item I write the cost in plain terms: this module caused three incidents last quarter, or every change to billing takes twice as long as it should. That makes it a conversation product can join. Then we do two things. We reserve a steady slice of each sprint for the top items, agreed with product up front so it isn't renegotiated every week. And when a feature touches messy code, we clean that area as part of the feature estimate. For the rare big rewrite, I'd plan it as a proper project with a clear goal and an end date, because open-ended clean-ups tend to never finish."

"I think a manager needs to be technical enough to follow a design debate, ask the question that exposes a weak assumption, and know when an estimate sounds off. What I avoid is owning code the team is waiting for, because my calendar will always win and I'll become the bottleneck. So I stay current in ways that don't block anyone. I read most of the design docs and join the reviews, I skim pull requests on the parts of the system I'm less familiar with, and I pick up small fixes or internal tooling. I also shadow an on-call shift now and then, which teaches me more about the real state of our systems than anything else. And when a senior knows more than me, I say so and ask them to walk me through it."