EM Interview: Product Deep Dive

This Deep Dive interview is designed to assess how an engineering manager leads a meaningful project from problem definition through execution and reflection. It uses a specific project chosen ahead of time by the candidate.

We are not evaluating whether the candidate designed or even understood every technical detail. We are evaluating whether they understood the work deeply enough to lead it well: shaping the problem, partnering across functions, structuring the team, staying close to key technical decisions, and learning from the outcome.

TL;DR The interview aims to understand five things:

1. Project ownership and problem clarity: Did they understand what problem the project was solving, why it mattered, where it came from, who was involved, and how it was prioritized?
2. Product partnership and role clarity: Did they help shape what to build, how success was defined, and how product trade-offs were made, or did they mostly manage engineering execution against someone else’s plan?
3. Team leadership and delegation: Did they structure the team’s work intentionally, know when to stay close versus step back, and manage the team through difficult or ambiguous decisions?
4. Technical judgment: Did they understand the architecture, requirements, scale, dependencies, trade-offs, risks, failure modes, and technical compromises well enough to challenge weak plans and lead effectively?
5. Outcomes and reflection: Did they understand whether the project succeeded, how it affected the business, product, team, or system, and what they learned about their own leadership?

---

#Recruiter Prompt to Candidates

Before the interview, candidates should be given a prompt at least a few days in advance to prepare.

#Instructions for Interviewer:

This is not a linear script. Use the questions as probes.

The goal is to understand the candidate’s actual leadership contribution. EMs can legitimately claim credit for decisions their team made if they shaped the direction, created the process, challenged the thinking, or held the bar. Push to understand the boundary between:

• What they personally drove
• What their tech lead or engineers drove
• What product/design/data drove
• What they influenced but did not own

---

#EM Technical & Product Deep Dive Interview

#0. Introductions (5 min)

1. Your name, role/team, how long you’ve been at Medium. Save a few minutes at the end for questions.
   • Introduce the shadow interviewer as well, if there is one!
2. Set expectations: “Today we’ll spend 5-10 minutes talking through the project you chose: the problem it was solving, your role, and who else was involved. Then we’ll spend 10-15 minutes on your role, 10-15 minutes on the technical details and tradeoffs, and 5-10 minutes on outcomes, reflections, and what you learned.
3. Any questions before we start?

#1. Project Overview (5 min)

Use this section to establish context. Choose a few of the following questions depending on what signal you’re looking for. Think of this as a ⚡ lightning round. Keep it short and don’t dive into details yet.

1. “To get us started, can you describe the project you chose?”

   Intro

2. “What problem were you trying to solve, and how did you know it was the right problem?”

   Look for whether they understood the customer, business, operational, or team need behind the work.

3. “Where did this project come from? Who originated it, and what role did you play in shaping the problem definition?”

   Look for if they helped define or sharpen the problem, not just receive a roadmap item.

4. “How many engineers were involved, and how was seniority distributed?”

   Look for intentionality around assignments.

5. “Who were the stakeholders and teams involved?”

   Helps calibrate scope and organizational complexity.

#2. Role, Product Partnership, and Ownership (10 min)

For a product-leaning role, we are looking for someone who is actively involved in the product strategy, not just someone who executes against a design.

1. “What was your specific role across the lifecycle of the project?”

   Sets the context for everything else. EMs often shift from shaping to unblocking to reviewing, and understanding the arc matters.

   Tip: probe for the arc: shaping, planning, staffing, execution, unblocking, launch, follow-up.

2. “Can you give a specific example of a product or technical decision you drove or significantly influenced?”

   This is one of the highest-signal questions. Good answers include scope changes, success metrics, sequencing, product simplification, customer insight, or pushback.

   Forces them to be concrete. Vague claims of “heavy product involvement” don’t count.

   SIGNAL: Look for candidates who pushed back on scope, proposed alternatives, defined success metrics, or redirected the product based on what they learned from the team or data.

3. “How did you define success for the project? Were the success metrics clear before the team started?”

   Strong EMs connect work to outcomes. Weak answers stay at “we shipped it.”

By this point, you should understand the scope of the project, the candidate’s product involvement, and their team’s shape. Move to the technical architecture.

#3. Team Leadership and Delegation (10 min)

Transition: “Let’s talk about how you led the team through the work.”

1. “Where did you stay close to the work, and where did you deliberately step back?”

   Look for their philosophy around delegation and empowerment. Identify what they value most, where they believe an EM adds leverage, and how they decide when to get involved versus when to let the team own the work.

   Listen for how they identify risk, how they evaluate whether the team is on track, and whether their involvement increases clarity without creating dependencies or friction.

2. “Can you share an example of when the team hit ambiguity, disagreement, or loss of momentum? What did you do?”

   Look for active leadership: clarifying decisions, escalating appropriately, resetting scope, improving communication, or changing operating rhythm.

#4. Technical Judgment (20 minutes)

Transition: “Let’s dig into the technical side. I’m not looking for you to prove you personally designed the system. I want to understand whether you were close enough to the technical decisions to lead effectively.”

These are not all required, and this does not have to be linear. Use them as follow-ups based on the project.

1. “What were the most important technical decisions the team made, and why?”

   Look for: Whether they understand the decision space, not just the final answer.

   Listen for: Alternatives considered, trade-offs, who was involved, and why the team chose the approach it did.

2. “How did you validate the technical plan?”

   Look for: Credible participation, even if they did not author the design.

   Listen for: Design docs, review forums, tech lead partnership, prototyping, operational review, security/privacy review, expert input, and what feedback they personally gave.

3. “What were the critical dependencies, risks, or failure modes? How did the team plan account for them?”

   Look for: Operational awareness and whether they thought beyond launch.

   Listen for: Pre-mortems, fallback plans, rollout strategy, monitoring, ownership, mitigation, or escalation paths.

4. “Were there any engineering principles you had to bend or set aside to meet deadlines or other constraints? Was it worth it?”

   Look for: Judgment, honesty, and understanding of the cost.

   Listen for: Whether they can distinguish pragmatic trade-offs from recklessness, and whether they learned anything from the decision.

#5. [OPTIONAL] Outcomes and Reflection (5 minutes)

If we have time, dive into these final questions.

Transition: “Let’s close with what happened after launch and what you learned.”

1. “What was the outcome of this project? How did you know if it succeeded?”

   Look for: Product, business, operational, or team outcomes beyond “we shipped it.”

   Listen for: Clear success metrics, how those metrics laddered up to company impact, and whether they can explain why the outcome mattered.

2. “Did this project leave the team, product, or system stronger than before? How?”

   Look for: Lasting impact beyond the immediate launch.

   Listen for: New architecture patterns, better team rituals, reusable infrastructure, sharper product insight, stronger cross-functional trust, and whether those improvements were intentional.

3. “If I asked your team, what would they say you did that was most helpful on this project? What would they say you could have done better?”

   Look for: Self-awareness, humility, honesty, and authenticity.

#Q&A (5-10 min)

Answer any questions they have, and be prepared to discuss the kinds of projects they’d own, the technical and product challenges ahead, and the impact they’d have.

Be honest about challenges too, without overselling the hard parts.

Note to interviewer: Capture screenshots of their final diagrams before the call ends.

#Rubrics, aligned with our EM career ladder

This interview primarily assesses how an EM leads a meaningful project from problem definition through execution and reflection. It does not assess every competency in the EM ladder. It is strongest for evaluating scope and impact, product partnership, team leadership, technical judgment, decision-making, and outcome ownership.

🙂 Good: Presents an appropriately complex project, explains the problem and why it mattered, describes their role clearly, and demonstrates ownership beyond coordination or status tracking. Can explain how the work was prioritized, how they partnered with stakeholders, how the team was structured, what major technical decisions were made, and how they knew whether the project succeeded.

🔥 Great: Shows clear ownership of impact, not just delivery. Understands what was built, why it mattered, how success was defined, and how technical decisions connected to product, business, customer, operational, or team outcomes. Demonstrates strong cross-functional partnership, intentional delegation, credible technical judgment, and honest reflection. Can discuss ambiguity, disagreement, technical debt, risk, and trade-offs without over-claiming credit or deflecting responsibility.

	L3 EM (Managing a Team)	L4 Sr EM (Managing a Complex Team or Area)	L5 EM / Director-Level
🌍 Scope, Ownership & Strategic Alignment	• Owns delivery and team health for a small team-scoped project.
• Can explain the problem, who was involved, and how the work was prioritized.
• Distinguishes their role from the roles of PM, design, data, tech leads, and engineers.	• Owns a more complex project, area, or multi-team effort.
• Helps shape the problem definition, priority, sequencing, and stakeholder alignment.
• Connects the project to broader product, business, or operational goals.	• Shapes company-impacting or foundational work across teams or functions.
• Defines or reframes important problems, aligns stakeholders around them, and connects project-level choices to broader strategy.
🧭 Team Leadership & Delegation	• Structures work clearly for the team.
• Assigns ownership intentionally, supports the technical lead, unblocks engineers, and creates growth opportunities.
• Can explain where they stayed close and where they stepped back.	• Leads through greater ambiguity or complexity.
• Balances speed, risk, redundancy, and engineer growth.
• Sets up leads and senior ICs to be effective.
• Handles disagreement, loss of momentum, or ownership gaps without becoming the bottleneck.	• Creates leadership systems that scale beyond their direct team.
• Develops EMs.
• Spots and fixes communication, ownership, or decision-making breakdowns across the organization.
⚙️ Technical Judgment	• Understands the architecture or technical design at a high level, including main requirements, components, dependencies, and scale.
• Can explain key technical decisions, alternatives, risks, and trade-offs, even if engineers made the final calls.
• Engaged enough to challenge a weak plan or ask credible questions.	• Engages with architecture, scale, reliability, cost, migration risk, dependencies, failure modes, and technical debt.
• Validates technical plans through appropriate standards or processes.
• Knows when engineering principles were followed and when they were deliberately bent.	• Has broad credibility across systems, domains, or disciplines.
• Identifies systemic technical risks and recurring patterns.
• Engineers trust their judgment even when they are not the deepest expert in the room.
• Helps raise the bar (technical, process, systems, rigor, product) across teams.
🤔 Trade-offs & Decision Quality	• Can describe meaningful product, technical, or prioritization trade-offs.
• Explains alternatives considered, why the team chose a path, and what compromises were accepted.
• Handles team-level ambiguity with judgment.	• Makes high-quality decisions across product, technical, and organizational constraints.
• Resolves ambiguity, drives alignment, and knows when to decide, defer, escalate, or revisit.
• Tracks or mitigates accepted debt and compromises.	• Makes high-quality decisions under broader uncertainty.
• Anticipates second-order effects across teams, systems, and business priorities.
• Helps the organization make clearer, faster, better trade-offs.
📈 Outcomes & Reflection	• Can explain the outcome using more than “we shipped it.”
• Understands whether the project succeeded and can reflect on what went well, what was hard, and what they would do differently.	• Connects outcomes to product, business, operational, team, or system impact.
• Understands whether the project left the team, product, or system stronger.
• Shows honest self-awareness about their leadership contribution and growth areas.	• Demonstrates lasting impact beyond the launch itself
• Reflects at the level of systems and leadership patterns, not just project execution.

#Red Flags

Note to interviewers: feel free to add more as you find them!

Watch for candidates who:

• Can describe execution but not why the work mattered
• Can describe the architecture but not the product or business trade-offs
• Credit the PM for all product decisions and themselves only for delivery
• Avoid naming hard calls, conflict, mistakes, or compromises
• Don’t give credit to others for their contributions