7 Must-Have Engineering Manager Stories That Will Land You the Offer
7 battle-tested stories from 50+ successful EM interviews!
This week’s newsletter is sponsored by Cerbos.
How to adopt externalized authorization: step-by-step roadmap.
Hardcoded authorization logic doesn't scale. As systems grow and requirements change, those tightly coupled permissions end up slowing down development, creating security risks, and making compliance a nightmare.
This 80-page eBook breaks down how hundreds of engineering teams have tackled this problem. It walks through the practical steps for moving from hardcoded permissions to externalized authorization.
What's in it:
Step-by-step adoption strategy from planning to PoC rollout
Frameworks, policy examples, code samples
Lessons from teams who've made the transition
If you're dealing with similar authorization complexity, this might save you some of the trial and error.
Thanks to Cerbos for sponsoring this newsletter, let’s get back to this week’s thought!
Intro
I held many engineering manager interviews in my career as an interviewer, and this is my top tip for being successful in a behavioral interview:
The most powerful thing that will showcase you as a competent engineering manager: Stories.
Good stories often mean the difference between landing the offer and not, and the reason is that they showcase your experience, the way you think, and your approach to solving problems.
So, the main question that we want to answer today is:
How to craft stories that will move the needle and get you the offer in your next engineering manager interview?
Luckily, we have Alexander Kliotzkin with us today. He is sharing in detail 7 must-have stories that will make you successful in EM interviews!
This is our second collab with Alex, and I highly recommend also reading the first article we did together to get a comprehensive overview of how to be successful in EM interviews:
Introducing Alexander Kliotzkin
Alexander Kliotzkin is an experienced tech leader with 16+ years in the engineering industry. He is a Director Of Software at Infineon and also a Career & Leadership Coach.
Together with Uzair Khan, Engineering Manager at Stripe, they are teaching a popular course called: Acing Engineering Manager Interviews, where they help EMs break through the interview process and land their Engineering Manager offer.
Check the course and use my code ENGLEADER10 for 10% off. The next cohort starts September 6.
The Harsh Reality About EM Interviews
After coaching over 50 engineering managers through interviews at Amazon, Meta, Palo Alto Networks, and countless other companies, I've witnessed a brutal truth:
Most talented EMs fail not because they lack experience, but because they don't understand what interviewers are actually evaluating.
EM interviews aren't about proving your technical prowess. They're psychological deep-dives into who you are when the pressure is on. They test your character, maturity, and emotional intelligence through behavioral stories.
Each question has an underlying leadership competency that interviewers are hunting for. They're not just listening to your story → they're analyzing:
how you think,
how you handle adversity, and
whether you have a systematic approach to lead a team through uncertainty.
Here's what I've learned from watching hundreds of interviews:
The candidates who get offers aren't the ones with perfect stories. They're the ones who can authentically demonstrate leadership competencies through real, messy experiences.
Very important: Don't fabricate the "perfect" story where you made all the right moves and saved the day. Interviewers will ask follow-ups, and if you've embellished, you'll get caught. Raw authenticity beats fictional perfection every time.
The 7 Leadership Competencies That Make or Break Your Interview
Every behavioral question maps to one of these core competencies. Master these stories, and you'll walk into any EM interview with confidence:
Managing underperformers → Managing people
Team motivation → Strong vision & influence
Sustainable delivery → Strong ability to deliver
Team scaling → Hiring and growing people
Stakeholder conflicts → Influencing without authority
Decision making under uncertainty → Strong judgment & instincts
Team Conflict Resolution → Managing Conflict
Let's dive deep into each one.
Story #1: Managing an Underperformer
"Tell me about a time you managed an underperformer"
This is hands-down the most common EM interview question. It evaluates your ability to build relationships, handle difficult situations, and make tough decisions when team performance is at stake.
Where Most Candidates Fail
They think they need to come out looking perfect. They either spend too long justifying their decisions or skim over the messy interpersonal details.
But here's the truth: This question evaluates exactly how you deal with conflict.
Interviewers want to see the difficult conversations, conflicting viewpoints, and real human dynamics.
Other red flags that kill your chances:
Passing decisions to HR or your manager
Waiting too long to act (hoping it resolves)
Saying "we made a plan" without specifics
Not showing backbone for difficult conversations
Glossing over interpersonal dynamics
Framework
Start with your philosophy, then show it in action:
Present your mental framework for handling underperformers and high performance teams
Establish your trigger point → what makes you act?
Show the difficult conversation → don't gloss over conflict
Detail your improvement plan → be specific
Own the outcome → good or bad
Share your learning → what would you do differently?
Story
Context & philosophy: "One of my senior engineers started missing sprint commitments over two consecutive sprints. His velocity dropped 40%, and team morale was suffering. My philosophy is simple: one underperformer affects the entire team's performance and sets dangerous precedents. But, I do my best not to jump to conclusions → I always seek to understand first."
Difficult conversation: "During our 1:1, I discovered he was struggling with our Spring Boot stack. He was a senior engineer I'd inherited, who had experience with Spring Boot, but never on major features. He felt insecure and was spending excessive time on basic concepts, which created a shame spiral."
Plan: "We created a development plan: paired him with a mentor, established weekly check-ins with specific output metrics, and set a 30-day improvement timeline. I also made it clear that future struggles needed immediate communication, not silent suffering."
Outcome & learning: "After a month, he was performing to expectations and became one of our strongest contributors. My key learning: I should have had clearer conversations about role evolution upfront. The upskilling conversation should have been proactive, not reactive."
Story #2: Keeping Your Team Motivated
"How do you keep your team motivated/engaged?" / "What's your leadership style?"
This question essentially evaluates your leadership style. Your ability to influence your team in a sustainable manner. Motivation is not a one-time act but a continuous process that goes beyond pep talks, free lunches, and short-term incentives. You need to show you understand what it takes to influence your team, and not just go by gut-feel.
Where Most Candidates Fail
They're all over the place without a structured answer, leaving the impression they don't have a real system. They rely on generic responses about team lunches and bonuses instead of demonstrating a thoughtful leadership philosophy rooted in concrete actions.
Framework
Present your system, then show it in action:
Your leadership philosophy on high-performing teams
How you connect individual goals to team/org objectives
The culture you intentionally establish and maintain
Concrete examples of guiding teams through adversity
Story
My motivation framework → "MAP"
Meaning → craft a story that links your work to customer & company impact
Autonomy → give ownership with clear guardrails and trust
Progress → make steady wins visible; celebrate learning as much as shipping
Situation: "Last year I inherited the Checkout & Payments team, 14 engineers who had just finished a stressful PCI audit. Two weeks later the CEO announced a fast-pivot: launch in three new countries within six months. Morale was shaky and burnout risk was real. My job was to re-ignite motivation, keep the team whole, and still deliver the multi-country launch on time."
Action (using MAP):
Meaning:
Ran a half-day off-site with a mission: "One-click checkout, anywhere in 200 ms."
Brought in Customer Support to replay actual cart-abandon calls so engineers felt the stakes.
Autonomy:
Met 1:1 with every engineer; mapped their growth goals to upcoming work (e.g., Brody wanted deeper infra work, took latency SLAs; Ana interested in leadership → owned Brazil payments track).
Published an OKR chart where people ranked what they wanted to work on.
Progress:
Introduced bi-weekly demo days and a "kudos bot" that posts user-facing wins.
Exposed live morale and delivery metrics on a public dashboard; if morale <7, we commit to one fix within a sprint.
Result: "Morale score rose by 10% in three months (pulse survey). Zero attrition, two senior engineers who were interviewing externally withdrew their applications. We hit the six-month launch; new-market GMV up 12% Q/Q, and our eNPS question “I understand and believe in the team vision” jumped 26 points."
Important to mention: MAP Framework gives me a repeatable playbook, start with purpose, pair autonomy with guardrails, and make progress visible to sustain motivation even under aggressive timelines."
Story #3: Ensuring Sustainable Delivery
"How do you ensure your team delivers sustainably?" / "What processes do you establish?"
Senior leaders don’t rely on intuition alone → they build repeatable systems. This question evaluates whether you have a structured approach to sustainable delivery, and if you can bring that playbook to your next role.
Where Most Candidates Fail
They don’t show a structured system. Their answers feel reactive instead of intentional → jumping from stakeholders to JIRA to leadership meetings without connecting the dots. The result is a vague, high-level response that doesn’t translate into concrete actions or repeatable processes.
Don't just say "we do standups, where we track JIRA tickets." Show a sophisticated system.
Example → my 3-layer delivery framework:
Layer 1: Strategic alignment (outside-in)
OKRs define direction and outcomes
KPIs + customer feedback measure success
Monthly business alignment meetings
Layer 2: Execution excellence (inside-out)
Sprint metrics for delivery cadence
CI/CD pipeline rigor
PR review standards and code quality gates
Layer 3: Team health (human-centered)
Weekly 1:1s with qualitative health checks
Regular retros + continuous improvement
Clear roles and career development paths
Story
Situation: "At my previous role, we were drowning in ad-hoc support requests that were derailing our sprint commitments. The team was frustrated, stakeholders were unhappy, and we had no visibility into why we kept missing deadlines."
My systematic response:
Implemented request intake process to track and prioritize interruptions
Enhanced CI controls to reduce production issues at the source
Created transparent metrics dashboard for stakeholder visibility
Established “interrupt budget” - 20% of sprint capacity reserved for urgent requests
Impact: "Support tickets decreased 40% over two quarters. Sprint predictability improved from 60% to 85%. Most importantly, the team felt in control of their work again instead of constantly reactive."
Story #4: Scaling Your Team
"Tell me about a time when you scaled your team"
Hiring is crucial to team culture and is the most important decision you'll make as an EM. This evaluates your ability to grow both people and processes while maintaining quality and culture.
Where Most Candidates Fail
They focus too much on the company hiring process, appearing passive. They don't emphasize their own philosophy, opinions, and leadership values in the scaling process.
Strategic Approach to Scaling
Start with business need, not headcount:
What business problem drove the need to scale?
How do you think about healthy team composition?
Attitude vs. competence? Culture fit vs. skill gap?
Bonus: For more senior roles, show how you are proactive in your hiring approach. You have a network of suitable candidates, you keep in touch with talented people you worked with before, and you have an intern program to find talented juniors. In short, you have a talent pipeline that you can call on anytime.
Story
Business context: "I was asked to lead the UI and observability charter for the Data Foundation team. I needed to build a team from scratch while facing an immediate deadline → a Big Tech Summit was just months away, and we had to deliver a demo-ready MVP."
My strategic approach:
Immediate foundation: "I negotiated with leadership to bring two high-performing engineers from my existing team to lay the foundation quickly. This gave us momentum while I built out the rest of the team."
Business-driven hiring strategy: "After working closely with architects and PMs to understand the technical roadmap and customer needs, I created a headcount forecast. Given our tight deadlines, I decided on a senior-heavy team who could operate independently and deliver effectively under time constraints."
My hiring philosophy: "I prioritize mindset over specific technical skills. I look for people who can operate with autonomy, collaborate effectively, and grow with the product rather than requiring extensive hand-holding. I want engineers who can evolve with our needs."
The process I established:
Designed a fair and inclusive hiring process within my org's framework
Worked with HR to source candidates from diverse backgrounds
Created standardized interviews with consistent questions
Ensured all interviewers were trained and calibrated
Onboarding for success:
Created tailored onboarding plans for each engineer based on their experience
Met with new hires daily during their first period to accelerate integration
Brought in mentors from the existing teams within the org for cultural alignment
Clearly communicated product vision, performance expectations, and success metrics
Results: "Over 6-8 months, I grew the team from zero to eight engineers. We successfully delivered our initial version on time for the Big Tech Summit. The team eventually grew to 15 members (including a merger that added five more engineers) with a 95% retention rate. We delivered 18 releases on schedule and contributed to $100 million in revenue."
Story #5: Managing Stakeholder Conflicts
"Tell me about a difficult situation with a stakeholder"
As an EM, you're the bridge between your team and the outside world. This evaluates your ability to influence without authority and build consensus under pressure.
Where Most Candidates Fail
They approach it the wrong way. Instead of showing how they built the relationship, they go on the defensive and spend their time justifying their position.
They talk about abstract groups → “the PM team” or “the org”, instead of focusing on the one individual they actually had to influence. And they skip over the messy details that interviewers really want to hear: the tension, the pushback, the conflict, and how they navigated through it.
This is fundamentally a relationship question. Interviewers want to see how you handle tension, build trust, and find win-win solutions when conflicts arise.
Story
Conflict: "Our primary PM wanted to commit to shipping three major features in a single quarter to hit an aggressive revenue target. Based on our team's velocity and the technical complexity, I knew this timeline was unrealistic and would likely result in technical debt that would slow us down for months."
Tension: "The PM's perspective was valid → the sales team had made commitments to enterprise customers, and missing the timeline could cost us significant deals. My concern was equally valid, rushing would create instability that could hurt existing customers."
My approach:
Understand first: Had a one-on-one conversation to understand their constraints and pressure
Used data, not opinions: Created a velocity analysis showing realistic timelines
Presented alternatives: Offered different scope combinations that could hit the timeline
Found the middle ground: Proposed shipping two features fully and one as a beta
Resolution: "We agreed to ship two features with full quality standards and launch the third as a limited beta with select customers. This allowed the sales team to demonstrate progress while maintaining our engineering standards."
Learning: "The key was reframing the conversation from “can't do” to “here's what we can do.“ When you come with solutions, not just problems, stakeholders become partners, not adversaries."
Story #6: Decision Making Under Uncertainty
"Tell me about a time you made a difficult decision without complete data"
EMs are paid to make difficult decisions on architecture, priorities, and strategy. This evaluates your decision-making process and risk tolerance.
Where Most Candidates Fail
They don't communicate their approach clearly and spend too much time on the situation itself → why it was difficult, the boundary conditions, potential pathways.
That's not what the question is asking. It's asking about your criteria to make the decision.
You also need to choose a story that truly shows you didn't have enough data. Often candidates talk about a difficult decision, but not because of lack of data.
Ensure your story addresses a situation where you truly didn't have enough information and needed to make a judgment call. That's the key: your judgment.
Framework
Show your mental model:
Gather available data (show you're not reckless)
Identify the decision criteria (what factors matter most?)
Assess risk vs. reward (what could go wrong/right?)
Make the call with confidence (show courage)
Create feedback loops (how will you course-correct?)
Story
The Crisis: "At my last org, we had a critical opportunity to materially increase customer cash inflows by launching Direct Deposit Switching in Q3. We faced a classic build-vs-buy dilemma: build payroll connectivity in-house (slow but controllable) or integrate with a third-party vendor like Pinwheel (fast but risky). Marketing had secured budget and a narrow launch window, but we lacked complete data on vendor coverage, employer-specific reliability, and real-world failure modes that could impact our compliance posture."
The data constraints:
No comprehensive data on vendor coverage across our customer base
Unknown failure rates by employer segment in production environments
Limited visibility into compliance risks and fraud patterns with third-party integration
Incomplete understanding of real-world setup friction and customer experience impacts
Marketing's Q3 window was non-negotiable → delay meant losing budget allocation and market timing
My decision-making process:
Framework application: "I immediately classified this as a reversible decision if we architected properly, then timeboxed the decision to two weeks. The cost of delay (missing Q3 inflows and budget) clearly outweighed the cost of being wrong if we built adequate guardrails."
Criteria definition: "Working with PM, Risk, and FinOps, I established concrete decision criteria: time-to-impact under 10 weeks, employer coverage above 25% of our MAUs, setup failure rate under 10% at launch, unit economics within model, and clear regulatory compliance with Reg E requirements."
Rapid uncertainty reduction: "I ran a 5-day integration spike with Pinwheel's sandbox, instrumenting both happy-path and error scenarios. We then conducted an internal beta with 100 employees plus 50 friendly customers to measure real drop-offs and error taxonomy."
External validation: "I made reference calls with two comparable fintechs and requested hourly success-rate logs from the vendor segmented by employer type → this gave us the missing reliability data we needed."
The outcome: "We chose the vendor partnership with explicit guardrails: feature-flagged staged rollouts, manual fallbacks, live-ops playbooks, and a kill switch for error rates above 15%. We launched MVP in 7 weeks versus the 4-6 months required to build in-house, and direct-deposit activations increased 3.8x quarter-over-quarter."
Key insight: "The decision to move at 70% information confidence was enabled by explicit rollback triggers and a pre-mortem that identified failure modes upfront. Sometimes protecting optionality through architecture is more valuable than waiting for perfect data → especially when the cost of delay is measurable and the decision can be reversed."
Story #7: Resolving Team Conflicts
"Tell me about a time you resolved conflict within your team"
As an EM, you're often the mediator when team dynamics break down. This evaluates your emotional intelligence and conflict resolution skills.
Where Most Candidates Fail
They typically present a technical dilemma, option A vs. option B and spend too much time on technical context. But this question evaluates your ability to manage difficult situations, get alignment, and make decisions when necessary.
The focus should be on the how and your philosophy of resolving issues. Managing each party before, during, and after. Just like with stakeholder and underperformer questions, don't gloss over messy details.
Show a systematic approach and demonstrate emotional intelligence by understanding motivations from both parties.
Framework
Remember: Most technical disagreements are interpersonal issues in disguise.
Recognize the trigger → when to step in vs. let the team resolve
Understand all perspectives → separate people from positions
Address root causes → usually communication or misaligned expectations
Facilitate resolution → guide, don't dictate
Follow up → ensure lasting resolution
Story
Technical conflict: "Two senior engineers were in heated disagreement about our architecture direction. One advocated for a webpack-based approach, while the other pushed for an ingress-based microservices approach. The conflict was blocking progress and creating tension in team meetings."
My initial assessment: "Through individual 1:1s, I realized both engineers were basing their strong opinions on online research rather than actual experimentation with our specific use case. Neither had concrete data to support their position."
My resolution:
Data-driven decision making: "Instead of picking sides or making an executive decision, I suggested we spend time doing POCs to collect actual data. I gave them a week to experiment with both approaches."
Structured evaluation: "I facilitated a session where both engineers presented their POC results objectively. We evaluated based on performance metrics, maintenance complexity, and team capability."
The decision: "The data clearly showed the webpack-based approach was superior for our specific needs, despite some initial downsides."
Managing the aftermath: "The engineer whose approach wasn't chosen was visibly disappointed. I had several follow-up conversations to emphasize that there was no “right or wrong” person → just a better solution for our specific product needs."
The key challenge: "The hardest part wasn't the technical decision, it was managing the ego and emotional investment each engineer had in their approach. I had to separate the person from the position and help them see this as a learning opportunity."
My learning: "I should have focused more on how I managed the disappointed engineer's emotions and kept the team aligned afterward. The technical resolution was straightforward once we had data, but the people management required ongoing attention to prevent lasting resentment."
Follow-up actions: "I implemented a new practice: whenever we have architectural decisions, we always start with experimentation and data collection rather than theoretical debates. This prevents ego-driven conflicts from the start."
The Truth About "Perfect" Stories
After watching hundreds of EM interviews, here's what separates offers from rejections:
❌ Rejected candidates:
Tell sanitized stories with perfect outcomes
Avoid conflict and difficult conversations
Focus on what happened, not how they thought
Present themselves as flawless leaders
✅ Successful candidates:
Share raw, authentic experiences with real challenges
Embrace the messy details of human dynamics
Focus on insights, learnings, and personal growth
Present themselves as thoughtful, reflective leaders
Remember: Interviewers aren't hiring the person who never makes mistakes. They're hiring the person who makes good decisions under pressure, learns from experience, and can lead others through uncertainty.
Final Thoughts: Your Stories Are Your Differentiator
In a world where technical skills are commoditized and frameworks come and go, your leadership stories are what make you unique. They reveal not just what you've done, but who you are as a leader.
The best EM candidates don't just have impressive resumes, they have compelling stories that demonstrate growth, wisdom, and the kind of leadership that others want to follow.
Your stories are waiting. The question is: are you ready to tell them?
Last words
Special thanks to Alexander for sharing his insights on this very important topic with us! Make sure to check him out on LinkedIn and also check out the course Acing Engineering Manager Interviews.
We are not over yet!
How to Grow From Senior Engineer to a Lead Role
We are starting the course Senior Engineer to Lead: Grow and thrive in the role next week on September 2 (the next cohort is going to be next year).
This video is a good introduction to what we are going to be discussing in the course. To learn what you need to do to grow to the lead role, check out the latest video!
New video every Sunday. Subscribe to not miss it here:
DevStats
Special thanks to Phil Alves and DevStats for being a long-term sponsor of this newsletter; they’ve sponsored 24 newsletter articles over the course of 2 years!
If you haven’t checked them out yet, they have an awesome product, which I have looked at extensively and also used in one of my projects → and it has helped us a lot.
Liked this article? Make sure to 💙 click the like button.
Feedback or addition? Make sure to 💬 comment.
Know someone that would find this helpful? Make sure to 🔁 share this post.
Whenever you are ready, here is how I can help you further
Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.
Interested in sponsoring this newsletter? Check the sponsorship options here.
Take a look at the cool swag in the Engineering Leadership Store here.
Want to work with me? You can see all the options here.
Get in touch
You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.
If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.
This newsletter is funded by paid subscriptions from readers like yourself.
If you aren’t already, consider becoming a paid subscriber to receive the full experience!
You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.
 | A guest post by
|