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.

Download free eBook

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:

How to Ace Engineering Manager Interviews Gregor Ojstersek and Alex Kliotzkin · Jun 29 Read full story

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:

1. Managing underperformers → Managing people

2. Team motivation → Strong vision & influence

3. Sustainable delivery → Strong ability to deliver

4. Team scaling → Hiring and growing people

5. Stakeholder conflicts → Influencing without authority

6. Decision making under uncertainty → Strong judgment & instincts

7. 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:

1. Present your mental framework for handling underperformers and high performance teams

2. Establish your trigger point → what makes you act?

3. Show the difficult conversation → don't gloss over conflict

4. Detail your improvement plan → be specific

5. Own the outcome → good or bad

6. 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:

1. Your leadership philosophy on high-performing teams

2. How you connect individual goals to team/org objectives

3. The culture you intentionally establish and maintain

4. 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:

1. Implemented request intake process to track and prioritize interruptions

2. Enhanced CI controls to reduce production issues at the source

3. Created transparent metrics dashboard for stakeholder visibility

4. 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:

1. What business problem drove the need to scale?

2. How do you think about healthy team composition?

3. 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:

1. Understand first: Had a one-on-one conversation to understand their constraints and pressure

2. Used data, not opinions: Created a velocity analysis showing realistic timelines

3. Presented alternatives: Offered different scope combinations that could hit the timeline

4. 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:

1. Gather available data (show you're not reckless)

2. Identify the decision criteria (what factors matter most?)

3. Assess risk vs. reward (what could go wrong/right?)

4. Make the call with confidence (show courage)

5. 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:

1. 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."

2. 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."

3. 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."

4. 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.

1. Recognize the trigger → when to step in vs. let the team resolve

2. Understand all perspectives → separate people from positions

3. Address root causes → usually communication or misaligned expectations

4. Facilitate resolution → guide, don't dictate

5. 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:

1. 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."

2. 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."

3. 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:

Subscribe to the channel!

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.

Check out DevStats

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!

Check the benefits of the paid plan

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.