Most engineering managers who get rejected in the loop fail a people question by answering it like an engineer. Asked how they’d handle a report who keeps missing deadlines, they run a root-cause analysis on the deadlines instead of making a plan for the person missing them. That reflex, reaching for the technical explanation when the interviewer wanted judgment about a human, is exactly what the EM loop is built to catch.
The loop itself is not mysterious. At most large companies it’s four to six conversations spread over two to four weeks: a recruiter screen, a hiring-manager behavioral round, one or two people-and-project rounds, a system design session, and a cross-functional or executive conversation near the end. A Series B startup will compress the whole thing into three calls and send an offer in ten days if they like you. The names change, but three interviews carry almost all the weight, and each one grades a different thing.
How the loop is actually shaped
Before the deep rounds there’s a filter you can fail without ever reaching the interesting questions. The recruiter screen checks scope: how many people you’ve managed, how many layers, whether you’ve hired and fired. The hiring-manager round is the first real read on judgment, and it usually sets the theme the rest of the panel will probe. Say you’re strong at growing senior engineers, and expect the people round to press exactly there.
| Interview round | What it grades | A question phrased the way it’s asked | How candidates lose it |
|---|---|---|---|
| Recruiter / hiring-manager screen | Scope and basic judgment: team size, hiring and firing experience, why you manage at all | “How big was your team, and how many were direct reports versus dotted-line?” | Vague scope, or a management story that’s really an IC story |
| People management | How you handle underperformance, feedback, and growing people | “Tell me about someone on your team who wasn’t meeting the bar. What did you do?” | A tidy story where feedback worked on the first try |
| Project and delivery | Planning, re-scoping, and owning a project that went sideways | “Walk me through a project that slipped. When did you know, and what did you change?” | Blaming the team or a dependency without owning the miss |
| Technical / system design | Whether you can drive tradeoffs and supervise senior engineers, not write code | “Design a notification service. Where would you push back on a senior engineer’s plan?” | Going quiet on tradeoffs, or trying to implement it yourself |
| Cross-functional / executive | Influence, values, and how you work with product and peers | “Tell me about a time you disagreed with a PM and had to make the call.” | Sounding like you win by authority rather than reasoning |
Read the table as a map of where the points live. The screens gate you in. The three middle rounds decide the hire. The final conversation is mostly a values and culture check, and while a bad one can sink you, a merely fine one rarely wins the offer on its own.
The people round wants the messy story, not the framework
This is the round senior engineers most often underestimate, and it’s usually the one that decides things. The main question comes in a few shapes: “Tell me about a report who was struggling,” “Describe a time you had to give feedback someone didn’t want to hear,” or the blunt version, “Have you ever managed someone out, and how did it go?”
The mistake is telling the clean version. A candidate describes a struggling engineer, says they gave clear feedback, and reports the engineer turned it around within a month. Interviewers have heard that story a hundred times and they don’t believe it, because real underperformance rarely resolves that neatly. They want the one where the first conversation didn’t land, where you had to decide whether to keep investing or move toward a plan, where you documented what was happening and kept the rest of the team from quietly absorbing the cost. The signal they’re grading is whether you acted early instead of hoping, and whether you protected the person’s dignity while you did it.
Growing a team gets tested from the other direction. “You’re given headcount for three engineers, how do you decide what to hire?” is not a question about how much you enjoy hiring senior people. A strong answer maps concrete gaps on the team to specific roles: you’re thin on anyone who understands the data layer, you have no one who can mentor the two juniors, so the mix follows from that. Weak answers describe an ideal candidate in the abstract and never touch the team that actually exists.
The project round is about delivery under real constraints
Here the prompt is almost always a project that went wrong. “Walk me through a project that slipped past its deadline.” “Tell me about something you shipped late, or didn’t ship at all.” The interviewer cares less about the outcome than about your relationship to the miss.
They’ll probe a specific sequence. How did you find out the project was behind, and were you surprised, because being surprised late is itself a finding. What did you cut when you re-scoped, and how did you decide what was safe to drop. What did you tell stakeholders, and when. The failure mode is a story where the slip was entirely someone else’s fault: a dependency team was late, the requirements changed, the engineers underestimated. Even when all of that is true, the interviewer wants the part you owned, the check you should have run two weeks earlier, the escalation you delayed because you hoped the problem would resolve on its own.
A related question shows up in most loops: two teams need the same person, or two priorities collide and you can only fund one. The point is to watch you make a decision with incomplete information and defend the reasoning, not to reach a correct answer. Candidates who dodge the tradeoff (“I’d find a way to do both”) score worse than candidates who pick one and stand behind it.
The technical round is not a coding test
Plenty of EM candidates over-prepare for this round by grinding algorithm problems, then walk into a system design session where writing code would actually count against them. Some companies still run a coding screen for managers, usually easier than the IC track, but the manager-specific technical interview checks something else: can you hold your own in a design discussion with engineers who are deeper in the stack than you are.
The scenario that separates people is an estimate you disagree with. A senior engineer tells you a database migration will take eight weeks. A manager who has lost their technical footing either accepts the number to avoid looking ignorant or overrides it with authority. The one interviewers want asks the questions that show they still understand the work: what’s the rollback plan, how much data are we moving, is there a dual-write window, what happens to in-flight requests during the cutover. You don’t need to know the answer. You need to know which questions make the estimate real, and to ask them without turning it into a status contest.
System design prompts follow the same logic. Design a rate limiter, a notification service, a feed. You’re graded on whether you drive the tradeoffs, sequence the work, and know where the risk sits, not on whether you can implement the token bucket from memory. Go quiet and let the interviewer lead, and that reads as a manager who can’t operate at the level of their own team.
The question that carries the most weight
Across every EM loop I’ve watched, the single most predictive question is some version of “tell me about the hardest conversation you had with someone on your team.” Managing out a low performer, delivering a bad review, telling someone the promotion isn’t happening this cycle. It shows up in the people round, and it comes back in the executive conversation, because it’s the closest proxy for the actual job that an interview can get.
The best answers have a specific shape. They name the moment the manager realized they’d waited too long, and what the waiting cost the team. They’re candid about the discomfort without performing it. And they end with what the manager did differently the next time, because the interviewer isn’t grading whether the hard thing went perfectly. They’re grading whether you’ll do it at all, early enough to matter, when it’s your own team on the other side of the table.
Practice the behavioral round:
