Most EM interview prep fails the same way. You pick three strong stories, polish them until they're tight, run them past a friend, and walk in confident. Then somebody asks how you'd handle a high performer who's difficult to work with, and none of your three stories touch it.
That isn't a depth problem. It's a coverage problem, and it's the thing that makes the EM loop different from every IC loop you've done.
An IC loop samples from a narrow surface. Systems, code, a couple of behavioural questions that mostly serve as tiebreakers. You can prepare for it by going deep on a small number of technical narratives.
An EM loop samples from a wide one. Nine areas, roughly, and you can be excellent at seven of them and still lose the loop on the two you never thought about.
The nine areas
- Team building and hiring
- Performance management and difficult conversations
- Conflict and difficult relationships
- Delivery, prioritization and ambiguity
- Cross-functional partnership
- Growth, coaching and career development
- Technical judgment and architecture
- Values, culture and self-awareness
- Vision and scaling
Look at that list and be honest about which two are thin for you. For most people coming from a senior IC role it's 2 and 3, because those are the parts of the job you've watched from the outside rather than done.
What the questions are actually checking
Underneath the surface wording, almost every behavioural question in an EM loop is checking one of four things.
Did you run a real process, or improvise? "I had a conversation with them" is an improvisation. "I named the specific pattern with dates, we agreed a 30-day plan, I checked in weekly" is a process.
Can you name a specific tradeoff you made, and why? Not that tradeoffs existed. Which one you picked, what it cost, and what you got.
Do you own outcomes without deflecting or over-apologizing? Both failure modes read badly. Blaming the org is worse, but flagellating yourself for four minutes over a bad hire is not much better.
Do you know which decisions were yours? This is where most candidates lose, and it's subtle. The story is real, the outcome is good, and the candidate narrates it as something the team did. If an interviewer can't find you inside your own story, they can't score you.
That last one has a practical use. When a question catches you off guard, don't stall. Answer the underlying one.
Build an inventory, not a script
The fix for a coverage problem is coverage.
Before you rehearse anything, write down eight to twelve real situations from the last two years. A hire that didn't work out. A project you cut scope on. A person you grew. An incident you ran and wrote up. A disagreement with your own manager that you lost.
Then go category by category and mark which of your situations covers it. Most of those 60-odd possible questions are answered by re-cutting one of your situations for a different angle, so the list fills up faster than you'd think.
The empty cells are the entire point of the exercise. Those are the questions that will catch you, and now you know which ones they are before you're in the room instead of after.
Then say each story out loud. Once. Not written, not memorized. The specific failure mode in an interview is rambling for four minutes on a question you know well, and you will not catch that by reading. You catch it by hearing yourself.
The shape of an answer
Ninety seconds, plus a hook.
- Situation and stakes, briefly
- What you specifically did
- What happened, with a timeline or a number if you have one
- One line on what you'd do differently
That last line is doing more work than the other three. It's the clearest thing separating a senior answer from a junior one, because it's evidence you've thought about the decision since rather than just filed the outcome away as a win.
An underperformer answer that ends "and by day 30 they were back to normal pace" is fine. One that ends "the thing I'd do differently: I let six weeks run before the direct conversation because I didn't want to look like I was jumping to conclusions, and I've since moved to checking in on delivery patterns closer to the two-to-three week mark" is a different candidate.
One more thing on wording: specificity beats sentiment, every time. Name the actual mechanism. A documented plan, a defined timeline, specific check-ins. Every candidate says they believe in giving people a fair chance, so saying it tells the interviewer nothing about you.
The case study round is testing something else
Some loops include a scenario round, sometimes as a discussion, sometimes as a role-play with the interviewer playing a team member. That round scores real-time judgment rather than a rehearsed story, which is why prepping for it feels impossible and mostly isn't.
The most common way to lose points here is jumping straight to a plan. It feels decisive. It reads as someone who doesn't ask questions before committing, which is a genuinely bad trait in a manager.
A structure that works on any prompt in this round:
- Clarify. Ask two or three questions before proposing anything.
- State your framework or priority order explicitly, out loud.
- Walk through concrete first steps.
- Name what you'd watch or check in on afterward.
Take "you inherit a team with high attrition and low morale, what are your first 30 days?" A weak answer announces changes. A strong one starts with 1:1 listening, not a survey and not a deck, works out whether the root cause is the work, the leadership, comp, or something structural, and picks one small visible fix in the first couple of weeks to buy trust before attempting anything bigger.
People who run these loops say much the same thing: candidates who clarify before answering score higher than candidates who answer instantly, even when the two eventually land in the same place.
The round nobody preps for
If the loop has an executive or skip-level stage, it's usually evaluating one thing. Would I trust this person to represent engineering in a room I'm not in?
Practical prep: be able to explain your team's work and its business impact, with no jargon, in under two minutes. If you tend to over-explain technical detail when you're nervous, this is the round to rehearse trimming, and it's a different muscle from everything else in the loop.
Reference checks are worth a mention too, because at EM level they tend to go past "would you rehire." Expect questions about how you handled a specific hard conversation and how your reports would describe your style. Tell each reference what the role actually emphasizes so their answer is specific rather than generic. Ask permission first, obviously.
One honest caveat
Management is not a promotion. It's a different job, with a different skill set and a different definition of a good day, and at most large companies the compensation bands run parallel rather than upward. Charity Majors' argument about the engineer/manager pendulum is worth reading in full before you commit to this track.
The test I'd offer: picture a day where you wrote no code, and three people on your team made progress they wouldn't have made without you. Was that a good day or a wasted one?
If it was wasted, stay on the IC track and go after tech lead or architect instead. A lot of the prep above still applies. The difference is you'd be answering the same questions about influence without authority rather than about headcount.
Disclosure so it's out in the open: I make career toolkits for engineers, and I pulled the categories and the answer structure above out of one of them. The full list of 62 EM interview questions, organized the way I've described, is a free PDF here. No email required. Everything useful in this post is in the post; the PDF is just the checklist version.
Top comments (0)