On this page
A different job, scored on different things
Who this is for
Senior individual contributors interviewing for a first-time engineering manager role, and current managers changing companies. If you are still proving you can do the work, this is about proving you can multiply other people doing it.
The thing that got you this loop, being a strong engineer, is now table stakes. The loop is no longer asking *"can this person solve the problem?"* It is asking *"can this person build a team that solves the problem, week after week, without them in the room?"* Those are different questions, and they are scored by different people, often including a director or VP and a cross-functional partner who has never read your code.
Most candidates lose here not because they lack judgment, but because they answer every question as the senior engineer they have been for years. The interviewer asks how you would grow a struggling teammate and gets a clean answer about how you would refactor the service. Right instinct, wrong job.
An IC is hired for what they can build. A manager is hired for what their team can build when the manager is on vacation.
How the EM loop differs from the IC loop
The shape of the day changes. You will see fewer pure coding rounds and more conversations that have no whiteboard. Here is what tends to replace what.
| The IC loop | The EM loop |
|---|---|
| Coding / data structures | People and leadership rounds: feedback, conflict, growth, hiring. |
| Deep system design you build | Team and delivery scenarios: how you run a team through ambiguity and missed dates. |
| Mostly engineers interviewing you | Cross-functional partners (product, design, support) probing how you collaborate and manage up. |
| Technical depth is the whole bar | A lighter technical or architecture round, enough to show you can still earn an engineer's respect, not to prove you are the strongest coder. |
| Impact framed as what you shipped | Impact framed as what the team shipped, and how you set them up to ship it. |
Pro tip
The lighter technical round is a trap if you treat it as your moment to shine. They are checking that you can hold a credible architecture conversation and ask good questions, not that you can out-engineer the panel. Show judgment and humility, then hand the floor back.
The people scenarios they will actually test
The behavioral and scenario rounds cluster around four situations. They are not looking for the textbook answer. They are looking for evidence you have sat in the discomfort and made a real call, and that you led with the person before you led with the process.
- Giving difficult feedback. Tell me about a time you told someone something they did not want to hear. They want directness paired with care, and a specific example, not a philosophy.
- Handling an underperformer. What do you do when someone is not meeting the bar? They are testing whether you diagnose before you judge, support before you escalate, and act before it festers.
- Resolving conflict. Two strong engineers disagree, or your team clashes with another team. They want to see you surface the real disagreement instead of smoothing it over.
- Supporting growth. How do you help someone level up, or get unstuck, or reach for the next role? This separates managers who grow people from managers who just assign work.
Answer all four with STAR, but make the R an outcome about a person or a team, not a deliverable. "The feature shipped" is an IC result. "She is now comfortable raising risks early, and led the next launch herself" is a manager result.
Structuring a people-scenario answer
When you get "tell me about a time you handled a difficult report," do not freelance. Walk these five beats. It keeps you specific, keeps the person at the centre, and lands on an outcome the interviewer can score.
- 1
Set the situation in one breath
Name the person's role, the stakes, and what was actually going wrong. Keep it to two sentences. The interviewer needs just enough to feel the weight of the call you had to make.
- 2
Show that you diagnosed before you judged
State what you did to understand the cause: the one-to-one you held, the question you asked, the thing you checked. This is the single biggest signal of managerial maturity. You looked before you labelled.
- 3
Describe the action you owned
What you specifically did, the conversation you had, the support or boundary you put in place. Use "I" for your decisions and "we" for the work. Avoid hiding behind "the team decided."
- 4
Name the human outcome
What changed for the person and the team. Improved, exited with dignity, regained trust, started raising risks early. Be honest if it ended in a managed exit. That is a real and respectable outcome.
- 5
Close with the reflection
One sentence on what you would do earlier or differently next time. It signals you treat managing as a craft you are still sharpening, which is exactly what they want to hear.
Team health, delivery, and the IC trap
Expect open questions like *"how do you think about team health?"* or *"how do you know a project is on track?"* These are not asking for a framework name. They are asking whether you reason about a team as a system: people, process, and delivery, and how those three pull on each other.
- Team health: talk about psychological safety, sustainable pace, attrition risk, and the quiet signals (people going silent, reviews getting terse) before they become resignations.
- Delivery: talk about predictability over heroics. How you size work, surface risk early, and protect the team from thrash, not how many features you personally drove.
- Process: talk about process as a tool you tune for the team, not a ritual you impose. The right amount of process is the least that keeps the work visible and honest.
Here is the trap, made concrete. The same question, answered as the IC you were, then as the manager you are interviewing to be.
Answered as an IC
If someone was underperforming, I would pair with them on the hard parts and probably take the trickiest tickets myself so the project still lands on time. I would review their pull requests closely and rewrite the parts that were not up to standard, and over time they would pick up the patterns from my code.
Answered as a manager
First I would find out why, because underperformance is a symptom, not a cause. In a one-to-one I would dig into whether it is clarity, skill, motivation, or something happening outside work. Then I would set explicit, written expectations and a check-in rhythm so we both know what "on track" looks like, and I would give them the support that matches the cause, mentoring for a skill gap, unblocking for an environment problem. If it did not improve, I would be honest early rather than carry it quietly, and move to a formal plan with HR. The goal is a fair shot and a clear outcome, not me silently absorbing their work.
- The IC answer solves the ticket. The manager answer solves the person, and protects the rest of the team from a problem the IC version just hides.
- "Take the trickiest tickets myself" is the tell. A manager who absorbs the work does not scale and leaves the report exactly where they started.
- The manager version diagnoses before acting, sets written expectations, and is willing to reach a hard outcome. That is the whole job in one answer.
- Notice the manager answer never mentions code quality. The problem was never the code.
Impact, and the questions that show maturity
When they ask about your impact, resist the highlight reel of things you built. Reframe everything as team outcomes. Not "I shipped the billing rewrite," but "I grew the team from three to six, set up the on-call rotation that cut after-hours pages by half, and the billing rewrite shipped without me writing the core of it, which is the point." The shift from *I made* to *I enabled* is the entire interview in one sentence.
The questions you ask them are scored too. Vague questions read as an IC who has not thought about the job. Sharp questions read as someone who already manages. Ask things only a manager would care about.
- "What does this team need from a manager in the first six months, fixing, growing, or steadying?"
- "How is success measured for managers here, and how much of it is team outcomes versus my own output?"
- "How are decisions made between engineering and product when they disagree, and where does the manager sit in that?"
- "What is the current state of the team, tenure, morale, any recent departures I should understand?"
- "How much room does a manager have to change process, hiring, or roadmap, versus inheriting it fixed?"
Managing up is part of the test
Cross-functional and skip-level rounds quietly probe how you handle your own boss and peers. When you describe a hard call, show that you kept your manager and partners informed, disagreed in private, and committed in public. A manager who only talks downward worries the people above them.
Walk in remembering this
- The EM loop scores what your team can do, not what you can do. Answer every question through that lens.
- The people rounds want STAR answers that land on a human outcome, with diagnosis before judgment.
- The biggest trap is answering as an IC: solving the code instead of enabling the person. Catch yourself.
- Talk impact as enablement. Replace "I built" with "I grew, I set up, the team shipped."
- The lighter technical round tests respect and judgment, not whether you are the strongest coder in the room.
- Your questions are an answer. Ask the ones only a manager would think to ask.
Reading is step one. Now do it for real.
When you're ready, the platform has live mock interviews and portfolio-grade capstone projects you can actually talk about.
Keep reading
This is general, educational career guidance, not legal, financial, immigration, or professional advice. Examples are illustrative and simplified. Norms vary widely by country, company, role, and over time, so always verify what applies to your own situation. Nothing here guarantees an interview, an offer, or any particular outcome.