To accelerate your growth see:

• Get Hired as an EM (CV & job search to actually get interviews)

• AI Behavioral Interview Coach (the best prep for your interviews)

• 1:1 Coaching (work with me)

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

The engineering manager role today isn’t the same as it was when most of us started. The expectations have changed in a few specific ways. If you’re preparing for an interview or designing a hiring loop, it’s worth understanding what changed.

Four things stand out.

System design rounds now expect the breadth and depth of a staff engineer. Behavioural interviews assume you’ve already rehearsed every common question. Hiring loops often stretch across four to six weeks. And AI fluency has become a near-universal topic.

Each of these signals what companies are really looking for in engineering managers today - and what they’ve learned from the managers they hired a few years ago.

The technical bar

System design used to be a warm-up in an EM interview loop. It isn’t anymore.

In most interviews I’ve seen over the past year, it’s assessed at the same level as a senior or staff engineer. Interviewers go deep on data stores, consistency trade-offs, back-of-the-envelope math, and scaling decisions. They’re not checking whether you can follow along. They’re checking whether you could lead the design yourself.

This change comes from a real problem. Many teams hired EMs who had completely let go of the technical side. Those managers struggled to weigh in on architecture decisions. They couldn’t push back on over-engineered proposals. They couldn’t coach senior engineers through difficult technical calls.

The cost showed up in growing technical debt and disengaged senior engineers.

I’ve written before about how experienced engineers lose influence when they can’t engage deeply in technical discussions. The same dynamic applies to managers. If you can’t hold the room during a technical conversation, you risk becoming a process layer instead of a leader.

If you’re hiring

Be honest about what the role actually requires.

If the job involves real technical judgment (reviewing architecture proposals, weighing platform choices, coaching senior engineers through system design) then a staff-level system design interview makes sense.

If it doesn’t, don’t run one just because the hiring template includes it. You’ll lose strong candidates to a test that doesn’t reflect the job you want to fill.

If you’re interviewing

This is one area where preparation genuinely helps.

Practice a few system design scenarios with follow-up questions. Do some back-of-the-envelope exercises to build your fluency. The goal isn’t to memorise architectures. It’s to move quickly through the standard structure so you have time left for the interesting decisions.

Behavioural rounds

The second change is more subtle.

Behavioural interviews used to reward candidates who could tell one or two strong stories with real reflection behind them. That still matters, but the volume has increased. A full interview loop now covers twelve to fifteen questions expecting very little repetition in your answers. And your answers need to follow the CARL format, backed by specific metrics.

CARL (Context, Action, Result, Learnings): the framework top interviewers use to evaluate behavioral answers.

The interview isn’t only testing whether you have experience in the role. It’s testing how you present relevant information, reason on the decisions you’ve made, understand your shortcomings, etc.

Two candidates with identical careers can perform very differently depending on how much they practice for this round.

If you’re running the interview

Pay attention to whether your behavioural rubric can distinguish between “didn’t prepare” and “hasn’t done the work”.

Most rubrics can’t.

One useful signal is to ask follow-up questions that go three layers deeper than the original story. Candidates who have rehearsed answers tend to run out of material. Candidates with real experience usually don’t.

If you’re preparing

Build a bank of around fifteen stories covering areas like conflict, delivery pressure, hiring, firing, performance management, stakeholder push-back, technical disagreement, and cross-team influence.

Then practice mapping questions to your stories until it becomes automatic.

It feels a bit mechanical because it is. But once you’ve done it, you will stop worrying about which story to tell and can focus on telling it well.

I’ve written more about why behavioural preparation is the neglected half of interview prep. I also built an AI interview coach around this exact retrieval problem after seeing it repeatedly with managers I was coaching.

Process length

Hiring loops that once took two or three weeks now often stretch to four, five, or even six.

Some of that comes down to calendar chaos. But most of it doesn’t. Companies run slow loops when the hire isn’t urgent enough to move faster, or when they’re not fully ready to hire and don’t want to say so.

For candidates, the consequence is that running interviews across different companies in parallel is more rare. The thing that used to create leverage in negotiations is now much harder.

Companies know this. Some even rely on it.

If you’re hiring

A slow process is a competitive disadvantage unless your candidate pool is extremely small.

The candidates who stay in a six-week process are often the ones with fewer options. That’s rarely the profile you’re hoping to hire.

If you want strong candidates, move faster. If you can’t, at least be transparent about the timeline so candidates can plan around it.

If you’re interviewing

Pipeline timing matters more than pipeline size.

Starting four interview processes in the same week means they’re likely to finish around the same time. Starting one process each week for four weeks usually means negotiating one offer at a time, with no leverage.

More broadly, the strongest candidates start building their network and reputation years before they need it. When the time comes to interview, the process moves much faster.

I wrote about this in more detail in a piece on landing senior leadership roles in big tech.

The signal hiding inside the questions

If an interview loop keeps circling back to questions about firing, PIPs, and managing people out, that’s usually a signal about the company, not about what makes a good manager.

Every EM needs to handle underperformance well. It’s a core skill. I’ve covered the mechanics of difficult conversations and performance management in The EM Field Guide.

But when four out of seven interviewers ask about it, they’re telling you something. The team is struggling, and they’re looking for someone to clean it up.

That might be the job you want. It might not. Either way, you’ve learned what the role actually is.

Interview processes leak information in both directions.

When you design an interview loop, it tells candidates something about your organisation. When you sit in one, it tells you something about theirs.

The questions that keep coming up are usually the real job description.

Closing thought

The hiring bar for engineering managers has changed toward hands-on, technically credible player-coaches who can also perform well under interview pressure.

That doesn’t mean every great EM role looks like this. Many don’t. But the hiring process has moved in that direction, and that’s the bar you’re measured against today.

If you’re hiring, design your interview loop to measure what the job actually requires, not what the market template suggests.

If you’re interviewing, treat preparation as a separate skill from the job itself. Drill the parts you can practice. And pay close attention to the questions companies ask you. They reveal as much about the role as your answers reveal about you.

You can’t control how long the process takes. But you can control how prepared you are when the call comes.

If you enjoyed this article, consider subscribing to get:

• ✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers

• 🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide

Subscribe now

You might also like some of my most popular posts:

See you in the next one,
~ Stephane

To accelerate your growth see:

• Get Hired as an EM (CV & job search to actually get interviews)

• AI Behavioral Interview Coach (the best prep for your interviews)

• 1:1 Coaching (work with me)

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

What Agent Orchestration Actually Changes: The Hidden Costs Behind Shared Understanding (Viktor Cessan)

tl;dr: Most of what managers do is “negentropy” - preventing shared understanding from degrading in three specific ways (state, semantic, verification). Agent orchestration is a phase shift that decouples output from coordination cost, not just a productivity bump.

The Economics of Software Teams: Why Most Engineering Organizations Are Flying Blind (Viktor Cessan)

tl;dr: A team of eight costs ~€87k/month. Break-even isn’t the right bar - a 50% initiative success rate means you need 3–5x cost in value to be financially viable, and almost nobody on the team knows these numbers.

15 Principles for Managing Up ()

tl;dr: A dense, tactical playbook with concrete before/after scripts for each principle. Lead with the punchline, show your thought process with conviction levels, bring solutions not complaints, proactively assert what to do rather than ask.

Mechanical Sympathy (Vicki Boykis)

tl;dr: The best engineers are also good product designers because both skills come from “mechanical sympathy” - an intuition for the grain of the system, built up over a human lifetime of context, that coding agents fundamentally lack. Agents fix code that already works, rewrite tests to assert wrong outputs instead of fixing the underlying bug, skip modern tooling defaults (uv, vectorized ops), and erode under iterative refinement - none of which are fatal alone, but collectively produce software that feels “hard” to develop.

Developer Ramp-Up Time Continues to Accelerate with AI ()

tl;dr: DX’s quarterly data shows Time to 10th PR dropped to 33 days in the latest cut (from 39 in Q4 2025, and 91 pre-AI), with the biggest driver being orgs now guiding new hires to use AI for codebase Q&A and draft changes rather than leaving it optional. Justin flags the honest limitation himself that 10th PR tells you nothing about code quality, rework rate, or whether you’ve just shifted the burden onto senior reviewers.

Most popular from last time

Why Your Engineering Team Is Slow

If you enjoy articles like these, you might also like some of my most popular posts:

What did you read recently that you would like to share?

Leave a comment

To accelerate your growth see:

• Get Hired as an EM (CV & job search to actually get interviews)

• AI Behavioral Interview Coach (the best prep for your interviews)

• 1:1 Coaching (work with me)

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

Most engineering managers carry around a ghost team. It is the team they worked on five or ten years ago where everything clicked: no ego, blameless retros, decisions made in ten minutes that would now take three meetings. They have spent every job since trying to get back there. And every time, it does not quite work.

The reason has nothing to do with the new people being worse, or the company being too big. It is that the kanban board, the lack of standups, the open Slack channels were outputs of trust, not inputs. Copy the outputs onto a team that has not earned the trust yet and you get the cargo cult version. It looks the same from the outside and feels nothing like it from the inside.

Process is scaffolding for trust you do not have yet. When the trust is there, you can take the scaffolding down and the building still stands. When it is not, you cannot.

What great teams actually had in common

The practices on great engineering teams vary wildly. Some pair-programmed all day. Some never paired. Some had a strict standup, some had no meetings at all. What was consistent across every version was three things, and none of them were practices.

People could be wrong without it costing them

When an engineer pushed back on a decision and turned out to be wrong, nothing happened to their standing. When something broke at 2am, the postmortem looked at the system, not the human.

This is the thing every “blameless culture” essay tries to describe. The actual mechanism is boring: leadership absorbed the political cost of mistakes instead of redistributing it down.

Decisions were cheap to make and cheap to revisit

The ghost team you remember probably did not have a great decision-making framework. It had people who could disagree in a meeting, commit afterwards, and bring it up again two weeks later if it was not working.

Nobody treated that as a loss of face. I have written before about the structural reasons engineers stop pushing back, and the through-line is the same: silence is almost always a sign that the cost of speaking up is higher than the cost of being wrong in private.

The manager was a shock absorber

Bad news from above got translated, contextualised, sometimes pushed back on before it reached the team. When something was non-negotiable, it was framed as such with the actual reason behind it.

Nobody had to pretend an executive whim was a brilliant strategic insight. This is harder than it sounds, because the path of least resistance for any manager is to pass pressure straight through. I have covered this in the piece on rants and transparency.

None of those three are practices. They are properties of a relationship, which is exactly why you cannot write them into a team charter on day one.

Building the foundation, not the rituals

If you cannot install the culture, what can you do? You create the foundation, deliberately, through small decisions that compound. None of these will feel transformative on day one. By month four, the team will feel different and you will not be able to point at the exact thing that changed.

Make one cheap, visible bet on trust per week

When an engineer says “I think we should do X” and you would normally say “let me think about it”, try saying yes instead, assuming the cost of being wrong is recoverable. Then make it obvious you are doing it.

“You said this would work better. Let’s try it for two sprints, I’ll back you either way”. The point is not the decision. The point is the precedent. After eight or ten of these, people start bringing you half-formed ideas instead of waiting until they are bulletproof.

Eat the first incident yourself

The first time something breaks in production after you join, your behaviour in the next two hours sets the tone for the next two years. Ask “who deployed this” and you have taught the team to hide. Ask “what did the system let us do that it shouldn’t have” and you have taught them the opposite.

Be obvious about it. Say it out loud, in the room. I have written more about how shallow understanding compounds into incidents, and the postmortem is where that compounding either gets caught or does not.

Translate, do not transmit

When news comes from above that you do not fully agree with, resist the urge to either hide it or repeat it verbatim. Work out what is actually being asked, what the constraint behind it is, and what you genuinely think about it. Then bring all three to the team.

The team does not need you to pretend everything from leadership is wise. They need you to show your work so they can do the same.

Run great 1:1s

Most 1:1s drift into status updates because status is the easiest thing to talk about. Resist that. If you are stuck for a starting point, I keep a generator with a few hundred questions that pulls a fresh set whenever I feel blocked. The questions matter less than the fact that you are signalling that the thirty minutes is for them, not for your status report.

Defend focused hours

One of the most under-appreciated things about the great teams in your past is that people had time to think. Not in theory between meetings, but actual blocks of three or four uninterrupted hours.

If calendars are getting shredded, you can model what good looks like with a focus time calculator and bring the numbers to your skip-level. “My team has 4.2 hours of focus time per week” is a more productive conversation than “we have too many meetings”.

A different way to think about the goal

If you do those things consistently for a quarter, you will start to notice something. Standups get shorter and more honest. Engineers tell you bad news earlier. Disagreements surface in the room instead of in the DMs afterwards.

None of that will be because you installed kanban or banned status meetings. It will be because you spent ninety days making it cheaper to be honest.

The team you are trying to recreate was not the way it was because of the practices. It was that way because someone, probably a manager you did not fully appreciate at the time, was doing the unglamorous work of absorbing pressure, eating mistakes, and making small bets on trust week after week. I put a lot of what I learned into the EM Field Guide, which is the closest thing I have to a single document on this kind of work.

The ghost team in your memory was not perfect either. You are remembering the feeling, not the receipts. What you actually want is not to recreate it, but to build a new team where the same conditions can take hold. That takes longer than you want it to, and the early days will look like nothing is happening. That is what compounding looks like before it starts to compound.

If you enjoyed this article, consider subscribing to get:

• ✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers

• 🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide

Subscribe now

You might also like some of my most popular posts:

See you in the next one,
~ Stephane

To accelerate your growth see:

• Get Hired as an EM (CV & job search to actually get interviews)

• AI Behavioral Interview Coach (the best prep for your interviews)

• 1:1 Coaching (work with me)

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

Why Your Engineering Team Is Slow (Ally Piechowski)

tl;dr: Introduces “codebase drag” and gives you a 5-signal scoring rubric (apology estimates, deploy fear, “don’t touch that” files, the coverage lie, time to first commit) to diagnose it. Worth reading if you’ve ever had to justify a refactor sprint to your product manager - it gives you a vocabulary and a number to put in front of them instead of vague “tech debt” hand-waving.

Encoding Team Standards (Rahul Garg)

tl;dr: Argues that AI coding instructions should be treated like CI configs or lint rules (versioned, reviewed, repo-resident artifacts) not Slack tips or tribal knowledge in seniors’ heads. The core insight is that AI-assisted development turns inconsistency between juniors and seniors into a systems problem you can actually solve: extract what the senior instinctively prompts for (architectural constraints, threat model, refactoring philosophy) and encode it as executable instructions with role/context/categorized-standards/output-format anatomy.

The Alarm That Went Silent ()

tl;dr: Teams optimize for the metrics they can see, while risk builds in areas that are harder to measure: team burnout, frustrated customers who haven’t churned yet, fragile systems, weakening culture, or slower decisions caused by too much process. Even more importantly, teams rarely stop to ask a harder question: how would we know if our metrics stopped telling the truth?

Say the Thing You Want (Matheus Lima)

tl;dr: Why engineers (and engineering managers) sit on what they want in 1:1s and how that tanks careers - managers have seven other reports and incomplete information, so an unspoken desire has zero surface area for anyone to help with. People confuse wanting something with working toward it, and saying it out loud to another person is what actually gives the goal weight and changes your behavior.

On the Socially Acceptable Use of AI in Business (Dave Kellogg)

tl;dr: Use AI however you want, but you are responsible for the result. Rejecting an idea just because AI helped create it misses the point. What matters is whether the idea is good. The real problem is presenting AI output as your own thinking when you haven’t read it carefully, challenged it, and corrected it. AI can help you work faster, but you still need to understand the work. If you let AI do the thinking for you, the mental skill you’re supposed to build will slowly weaken.

Most popular from last time

How Do You Know If You’re a Good Leader?

If you enjoy articles like these, you might also like some of my most popular posts:

What did you read recently that you would like to share?

Leave a comment

To accelerate your growth see:

• Get Hired as an EM (CV & job search to actually get interviews)

• AI Behavioral Interview Coach (the best prep for your interviews)

• 1:1 Coaching (work with me)

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

You’ve got a Senior Engineer or Tech Lead who used to be the gravitational centre of your team. When things broke, they fixed them. When nobody could figure out why the service was choking, they found the problem. When architectural decisions needed to be made, people looked at them.

Now they come to you frustrated. “Nobody listens to me anymore.” Or worse, they don’t come to you at all - they just disengage.

What happened is subtle. The mechanism that senior engineers used to build trust (being the person who solves the problems nobody else can) has been undercut. Not elim…

Read more

To accelerate your growth see:

• Get Hired as an EM (CV & job search to actually get interviews)

• AI Behavioral Interview Coach (the best prep for your interviews)

• 1:1 Coaching (work with me)

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

What Kinds of New Debt Are Teams Accumulating with AI? ()

tl;dr: Technical debt (code), cognitive debt (team understanding), and intent debt (missing rationale/design docs). AI may actually reduce technical debt while accelerating the other two, because the friction of writing code by hand is what builds understanding.

Software Engineering Splits in Three (Matteo Collina)

tl;dr: AI doesn’t just change how software gets built - it’s causing the industry to fracture into three genuinely different tiers with diverging skill requirements. Tier 1 (tech companies) needs senior reviewers of AI output, Tier 2 (enterprises) needs platform guardrails plus fractional senior expertise, and Tier 3 (small business) creates a “software plumber” role. Also raises an important question: if juniors no longer learn through working on tickets, where do your future senior engineers come from?

What About Juniors? (Marc Brooker)

tl;dr: Marc makes a compelling case that the junior engineer path needs to fundamentally shift - less time in the craft-of-coding apprenticeship, more early exposure to customers, economics, business constraints, and real ownership. The core argument is that engineering is about optimal solutions under competing constraints (people, money, tech), and juniors need to engage with that full picture much earlier than before. His advice to managers: give juniors a project to own, a customer to talk to, a deadline to hit, and a pager to carry.

Nobody Is Coming to Save Your Career ()

tl;dr: An Amazon Principal Engineer says: your manager isn’t your career coach (they’re too busy), your timeline is your responsibility (not the system’s), and your company’s incentives actively benefit from your comfortable stagnation. This is more of a “career wake-up call” than anything else, but the specific tactics are solid. Worth sharing with senior ICs on your team who seem stuck but haven’t initiated the conversation.

How Do You Know If You’re a Good Leader? ()

tl;dr: Uses Lincoln’s private self-doubt journal as a frame to argue that introspection isn’t imposter syndrome - it’s a leadership discipline. The practical core is a three-angle self-evaluation model (how your boss, peers, and team each experience you) and a useful reframe on feedback: if it’s correct, act on it; if you disagree, you still own the perception.

I’m an Introvert. This Is How I Get Myself to Speak Up. ()

tl;dr: Decide to speak before the meeting starts (not during), speak early to avoid getting scooped, use writing as a visibility strategy, and prep go-to phrases to buy yourself time. If you have quiet high-performers, try the accountability-buddy approach - DM them in meetings with a low-pressure nudge to chime in.

Most popular from last time

How We Hire Engineers When AI Writes Our Code

If you enjoy articles like these, you might also like some of my most popular posts:

What did you read recently that you would like to share?

Leave a comment

To accelerate your growth see:

• Get Hired as an EM (CV & job search to actually get interviews)

• AI Behavioral Interview Coach (the best prep for your interviews)

• 1:1 Coaching (work with me)

Subscribe now

PS. Paid subscribers get my 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

You’ve seen the dashboard. Your team’s PR throughput is up thirty percent. Tickets close faster. On paper, your team looks more productive than ever. The “AI era” has arrived, and the metrics seem to prove the investment was worth it.

But talking to your senior engineers, the vibe you feel is different. They’re exhausted. They feel like they’re drowning in a sea of what several practitioners call “slop”. While the “typing” part of the job has been compressed, the cognitive load of shipping a single feature has actually intensified.

We are currently living through a m…

Read more

I want to tell you about something I can’t stop thinking about.

Last year I watched a Software Engineer bomb a behavioural interview. He was smart, had 12 years of experience, and did really well in the previous rounds.

He presented a good story, too. He led a platform migration, handled stakeholder pushback, and managed to deliver on time.

Then my peer interviewer asked: “What was the measurable impact of this project?”

The candidate froze, rambled for 90 seconds, and then said something like: “We delivered it on time.”

Ultimately, he didn’t get the job... and that job paid £120k.

I’ve seen this happen over and over. Experienced people who know their stuff but can’t show it during an interview. They have enough stories but they just haven’t practised saying them out loud in a way that lands to interviewers.

Coaching with a human helps, but at £150-200/hour, you cover maybe 4-5 questions per session. You need 5-10 reps on each question before you actually get good at it. D…

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

Your best senior engineer is likely hitting a wall right now. They’ve spent the last eight years mastering the “how” of software development. They can out-code anyone, they know the legacy quirks of your database, and they never miss a ship date. Yet, in your 1:1s, they sound restless. They look at AI tools handling the “grunt work” of coding and feel like their craft is losing its value. They want that Staff title, but they think the path involves getting even deeper into the stack or mastering yet another framework.

The problem is that you might be reinforcing this. If you are still measuring them by th…

Read more

To accelerate your growth see:

• Get Hired as an EM (CV & job search to actually get interviews)

• AI Behavioral Interview Coach (the best prep for your interviews)

• 1:1 Coaching (work with me)

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

I have sat through hundreds of interviews for senior and staff-level roles. There is a specific kind of heartbreak that happens when a candidate with fifteen years of experience walks into the room and starts talking like they just finished their third year of work.

They have the resume. They have the years. They’ve seen big production outages and managed complex migrations. But when they open their mouth to describe their work, they talk about tickets. They talk about tech stacks. They talk about “doing what was asked”.

If you have been at a large consulting firm or a massive mega-corp for a long time, you might have developed what I call the good soldier habit. You show up, you solve the technical problem, and you stay out of the politics. In that environment, being “good” means being invisible and efficient. But when you try to move into a high-growth product company, that invisibility is a liability.

The biggest mistake experienced leaders make during a career jump isn’t a technical one. It is a narrative one. They fail to realize that at this level, I’m not just checking if you can write the code. I’m checking to see if you can own the outcome.

The mid-level IC mindset

When I ask a senior candidate to “tell me about a project you’re proud of” the mid-level response is usually a list of technologies. “We used Java and Spring Boot to build a microservice that handled 50,000 requests per second”.

That is a fine answer for a junior dev. For someone with 14 years of experience, it’s a red flag. It tells me you were focused on the tools, not the “why”.

A leader’s narrative needs to be about judgment. I want to know about the trade-offs. Why did you choose that specific architecture? Who did you have to convince? What went wrong three months in, and how did you handle it?

If you describe your work as “nothing special” or “just a basic API”, you are telling me your impact was negligible. You are dismissing your own expertise before I even have a chance to evaluate it. When you speak about your work with a dismissive attitude, it makes it impossible for an interviewer to feel confident in your leadership.

Judgment beats syntax

The reality is that anyone can learn a new framework. What you can’t teach easily is the ability to navigate ambiguity.

Experienced engineers often think they are being humble by saying, “I just did my job”. In an interview, that sounds like, “I don’t understand the business value of what I do”.

Leadership is the act of making decisions when there is no perfect answer. If every project you describe sounds like it went perfectly according to plan, I suspect you weren’t actually in the room when the hard decisions were made. I’m looking for the messy parts. I want to hear about the stakeholder who hated your plan and how you sat down with them to find a middle ground. I want to hear about the time you pushed back on a deadline because the technical debt was going to cripple the team.

That is the difference between a coder and an engineer. A coder implements the requirement. An engineer questions the requirement and finds the most effective way to solve the underlying problem.

How to build your story bank

You cannot walk into these rooms and hope the right story pops into your head. You have to treat your career history like a codebase that needs an index.

I tell people to prep six to eight core stories. You don’t need a different story for every possible question. You need a few high-quality ones that you can adapt. These stories should act as your “greatest hits” that demonstrate your judgment in different scenarios.

Your bank should include specific examples of:

• A time you handled a direct conflict with a peer or manager.

• A project that was failing and how you got it back on track.

• A situation where you had to lead people who didn’t report to you.

• A technical decision you made that you now regret (and what you learned).

• A time you had to deliver bad news to a stakeholder.

When you tell these stories, use a clear structure. Set the scene quickly, describe the specific actions you took, and then focus on the result. But the “result” shouldn’t just be “the feature shipped”. It should be about the impact on the team or the business.

(If you’re preparing for interviews, I made a Voice AI coach that practices this kind of narrative-building with you - it’s worth a try)

Position yourself

If you are trying to move from a “mega-consultancy” or a legacy firm to a modern product company, you have a positioning problem. Most people frame this move as “trying to get out” of a bad situation.

“I’m tired of the bureaucracy” or “I want to work with better tech” sounds like you are running away.

Instead, frame the move as an intentional choice. You want deeper ownership. You want to see the long-term impact of your architectural choices rather than shipping a project and moving to a new client. You want to be closer to the product and the users. This shift in framing makes you look like a leader who knows exactly what environment they need to be successful.

Getting the reps in

Interviewing is a specific skill that has nothing to do with your day-to-day work. If you haven’t interviewed in several years, you are going to be rusty. You will ramble. You will use verbal fillers. You will get stuck on a detail that doesn’t matter.

The only way to fix this is practice. Record yourself answering common questions. It’s a miserable experience to watch yourself on video, so you can also practice with the Voice AI Interview Coach.

If you have colleagues who have already made the jump to companies you admire, ask them for a mock interview. Don’t ask for a “coffee chat”. Ask for a thirty-minute session where they grill you and give you the cold, hard truth about your answers. I can also help you with that.

Understanding the other side of the table

Interviewer fatigue is real. Most people interviewing you have been in meetings all day and have two more candidates after you. If you can make their job easier by being clear, concise, and even a little bit human, you are ahead of 90% of the applicants.

A well-placed bit of humor or a brief moment of vulnerability - admitting to a mistake you made five years ago - builds more trust than any list of certifications would. They aren’t looking for a perfect machine. They are looking for a senior leader they can trust in a crisis.

Leadership is a craft you develop over time. Interviewing for those roles is the final test of that craft. You have the experience. You have the scars. You just need to stop hiding them and start telling the story of what they taught you.

If you enjoyed this article, consider subscribing to get:

• ✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers

• 🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide

Subscribe now

You might also like some of my most popular posts:

See you in the next one,
~ Stephane

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

Somewhere on your team right now, an engineer is spending five minutes rewriting a two-sentence PR comment. They’re softening it. Adding a “maybe” here, a question mark there. Wondering if “consider” sounds too commanding or too passive. They’ll eventually settle on something that sounds polite but vague enough that the author won’t know whether to act on it.

Meanwhile, another engineer on your team is writing “just do X” and hitting submit without a second thought. Not out of malice - they just want to get through open PRs before standup.

Both of these people think the other one is doing it wrong. And you…

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

Six Rules for Designing Company Goals ()

tl;dr: Goals exist purely to create clarity, not to represent every department’s priorities. No more than three company goals, one clear winner when metrics conflict, explicit non-goals, and a single accountable owner per goal.

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

Nobody gets rejected from an Engineering Manager role because they couldn’t invert a binary tree. They get rejected because when someone asked “Tell me about a time you influenced a technical decision across teams” they rambled for four minutes and never got to the point.

I’ve been on both sides of this. As a hiring manager, I’ve watched brilliant engineers give behavioural answers so vague they could apply to literally any job. As someone who’s interviewed for leadership roles myself, I’ve felt the particular panic of knowing you’ve done the work but not being able to find the words for it during the interview.

The technical rounds get all the prep. But it’s often the behavioural interviews that lead to rejections - and almost nobody prepares for them properly.

The preparation

Think about how engineers prepare for technical interviews. They grind leetcode for weeks. They do system design practice with friends. They buy courses, read books, time themselves solving problems. The preparation infrastructure is enormous.

Now think about how those same engineers or engineering managers prepare for behavioural interviews. They Google “common behavioural interview questions” the night before. They read the list, think “yeah, I could answer those” and go to bed. Maybe they skim the company’s leadership principles on the morning of.

That asymmetry would be fine if behavioural rounds didn’t matter much. But at the senior, staff, and management levels, they often matter more than the technical rounds. At Amazon, your leadership principles performance can tank an otherwise strong packet. At Google, the hiring committee weighs “Googleyness and leadership” alongside coding. At Meta, the behavioural bar for M1 and above is explicit and high.

You can ace every technical screen and still get a “no hire” because your behavioural answers were bad. (This is the problem I built my AI interview coach to solve - more on that below.)

Why this round is so hard

Coding is explicit. You write a function, it works or it doesn’t, and the logic is visible on screen. Leadership is the opposite. Your best work is often the stuff nobody saw, the conflict you defused before it reached the team, the reorg you navigated without losing anyone, the conversation with a product manager that prevented a three-month detour.

None of that feels like a “story”. It feels like Tuesday. So when an interviewer asks “tell me about a time you dealt with a difficult stakeholder” experienced engineers skip over the genuinely impressive thing they did and reach for something more dramatic that they can’t explain as well.

There’s a cultural problem too. Engineering culture rewards “let the work speak for itself”. Which is fine for the day job, but it’s disastrous in an interview where you’re literally being asked to speak for your work. Engineers who resolved serious team conflicts describe their role as “I just facilitated a conversation”. Engineers who changed how their entire org approached technical debt say “it wasn’t really a big deal”. The instinct to minimise is strong, and it’s the opposite of what a behavioural interview rewards.

And then there’s the practice problem. You can do a hundred leetcode problems alone at your desk. You can’t practise behavioural answers alone at your desk - or at least, you can’t practise them well. You need to say the words out loud, to someone who will push back, ask follow-ups, and tell you where your answer fell apart. The gap between how a story sounds in your head and how it sounds when you actually say it to another person is enormous. Most engineers discover this gap in the interview itself, which is the worst possible time to discover it.

What actually makes a strong behavioural answer

Before I get to what I built, it’s worth being specific about what interviewers at this level are listening for - because it’s not what most people think.

They’re not looking for a polished performance. They’re looking for evidence of judgment. When this person faced an ambiguous situation with competing priorities and no clear right answer, what did they do? How did they reason about it?

That means the strongest answers share a few qualities. They’re specific - numbers, trade-offs, not “we had a tight deadline” but “we had six weeks to migrate 200,000 users and the product team wanted to ship a new feature in the same window”. They have a clear decision point - a moment where you chose one path over another and can explain why. And they show self-awareness - what you’d do differently, what you missed, what you learned.

Following the STAR framework mechanically isn’t enough. “The situation was X, the task was Y, the action was Z, the result was W” sounds like a book report about your own career. The texture matters - the follow-up probes are where the real evaluation happens, and most engineers haven’t practised going a layer deeper than the surface story.

If you’re enjoying this article, consider subscribing to get:

• ✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers

• 🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide

Subscribe now

So I built something to close this gap

I kept running into this problem. Engineers and managers I managed, mentored, or interviewed - strong technical leaders who couldn’t talk about their own leadership. The fix was always the same: practise out loud, get feedback, iterate. But the options for doing that were limited.

A human interview coach costs £200–700 per session (I am just below that). Friends are helpful but rarely give honest, structured feedback - they don’t want to tell you your answer was weak. And practising in your head doesn’t work because you never discover the gaps until you’re speaking to another person.

So I built a Voice AI Interview Coach specifically for engineering leaders.

How it works. You pick a behavioural question from a bank of 130+ questions pulled from real interviews at Google, Amazon, Meta, and Stripe. You answer by voice, like in a real interview. The AI doesn’t just listen passively - it follows up with probing questions, exactly the way a strong interviewer would. “What did the other person think about that?” “How did you measure the impact?” “What would you do differently?”

After the conversation, you get a detailed scorecard across six dimensions:

• STAR structure

• specificity

• leadership signal

• impact articulation

• conciseness

• self-awareness

Not a generic “good job” - actual scoring with specific quotes from your answer and concrete suggestions for improvement. Plus a model answer so you can see what a strong response looks like.

The questions are categorised by role (Engineering Manager, Senior EM, Senior Engineer, Staff/Principal) and by competency - leadership, conflict resolution, technical decision-making, stakeholder management, delivery, hiring, the full spread. You can practise the same question as many times as you want. Most people score noticeably better by their third or fourth attempt, which is exactly the point.

Try your first question

ChatGPT won’t get you there

I know what you’re thinking. “I’ll just practice with ChatGPT” - and I’ll tell you now, I’ve tried to do it and it was just not good enough. That’s why I built this product for me in the first place.

Yes, you can talk to ChatGPT and get a spoken response. But there’s a difference between a general-purpose chatbot that can do voice and a tool built specifically for interview practice. A few differences, actually.

First, getting ChatGPT into a mode where it behaves like a competent interviewer takes real prompt engineering. You need to tell it which role you’re interviewing for, what competency to assess, how to probe, when to push back, what scoring criteria to use. You will either spend hours prompting it, or get a very mediocre experience (you’ll be hearing “That’s a great answer!” a lot).

Second - and this was my bigger problem - nothing is saved. You finish a solid answer and although it’s saved in the history chat, it’s difficult to compare your first attempt to your fourth. You can’t review what you said last Tuesday and figure out why that version was stronger. There’s no scorecard, no progression tracking, no way to see whether you’re actually getting better or just getting more comfortable hearing yourself talk.

Third, ChatGPT doesn’t know what good looks like for your specific level. The follow-up questions an interviewer asks a senior engineer are different from the ones they ask an EM or a staff engineer. The evaluation criteria are different. What counts as strong “leadership signal” at L5 versus L7 is different. A general-purpose AI treats all of these the same way.

The Voice AI Interview Coach was built for exactly this problem. You pick from 130+ questions pulled from real interviews at Google, Amazon, Meta, and Stripe - categorised by role level and competency. You answer by voice. The AI follows up the way a trained interviewer would: “What did the other person think about that?” “How did you measure the impact?” “What would you do differently?” Not generic encouragement. Actual probing.

After the conversation, you get a detailed scorecard across six dimensions - with specific quotes from your own answer and concrete suggestions for improvement.

Plus a model answer, so you can see what a strong response actually sounds like at your level.

Every attempt is saved. You can practise the same question five times and watch your scores climb, which tells you something important: the practice format itself was the bottleneck. Now you can practice each question as many times as you want.

(Your first question is free. Try it once and you’ll feel the difference between a chatbot that can talk and a tool that can coach.)

The maths

A single session with a human interview coach costs more than an annual subscription to this tool. For £24.99/month you get unlimited practice across every question, every role level, every competency. Your first question is completely free, no account needed.

If you’ve got an interview coming up, the ROI on a few hours of structured behavioural practice is hard to beat. The difference between a first attempt and a fifth attempt is usually the difference between “not enough signal” and “strong hire”.

Try your first question

I’ve been on both sides of the interview table for years. This is the tool I wish existed when I was preparing for my own leadership roles, and the one I now point engineers toward when they’re getting ready for theirs.

Start Practicing Now

If you enjoy articles like these, you might also like some of my most popular posts:

See you in the next one,
~ Stephane

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

Building An Elite AI Engineering Culture In 2026 (Chris Roth)

tl;dr: AI is a multiplier, not an equalizer: Taste × Discipline × Leverage. Senior engineers get 5x the productivity gains from AI tools vs juniors, and PR review times jumped 91% even as output increased. Specific practices from Linear, Stripe, Cursor, and Vercel: spec-driven development before prompting, stacked PRs to solve the AI-generated review crisis, AGENTS.md as a curated (not auto-generated) team artifact, vertical slice architecture for AI-friendliness, cycle time replacing story points, and the Design Engineer role dissolving traditional handoffs.

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

You know that feeling at the end of the day where you look at your calendar, scan your Slack history, and realise you spent six hours... reminding people to do things they already know they should do?

Update the ticket. Review the PR. Flag the blocker. Close the loop with the other team. You said it in standup. You said it in the 1:1. You said it in a DM. And somehow, here you are, saying it again.

It’s exhausting. And the worst part is that it feels productive in the moment (you are keeping things moving) but deep down you know something’s wrong and you shouldn’t be spending your time like this.

Constant f…

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

One List to Rule Them All ()

tl;dr: The word “priority” was singular for 500 years; we only started pluralizing it in the 1900s, and that linguistic shift gave us permission to avoid hard decisions. Maintaining a single stack-ranked list (no ties, no tiers) is a forcing function that externalizes debate and makes trade-offs visible - the discomfort of creating it is precisely the point, because it surfaces the conversations you’ve been avoiding.

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

There’s popular career advice aimed at engineers: keep a brag doc, schedule skip-level 1:1s, post your wins in Slack, update your manager after every your big wins. The advice isn’t wrong, exactly. It works. Engineers who do this stuff consistently do get promoted faster.

But if you’re an engineering manager reading that list, you should feel uncomfortable. Because every item on that list is a symptom of a system you’re supposed to be running - and it’s clearly not working.

When an engineer has to build an entire personal marketing apparatus just to get recognised for doing their job, something has broken …

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

14 More Lessons from 14 Years at Google ()

tl;dr: A dense collection of actionable leadership frameworks. Standout insights: “trust is a latency optimization for teams” (high-trust teams make decisions in hours, not weeks), the four-word meeting test (approve, choose, unblock, or inform - if you can’t pick one, cancel the meeting), and “when you add a team, you add edges, not just nodes” as a way to explain why doubling headcount doesn’t double output.

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

Something strange is happening on your team right now.

Pull requests are moving faster. Sprint velocity looks great. Your engineers seem productive and your stakeholders are happy. But when a production incident happens (and it will) you’re going to discover that nobody actually understands the system they built. Not deeply. Not in the way that lets someone trace a cascading failure across three services at 2am.

This is the comprehension gap, and it’s growing on every team that’s adopted AI-assisted development without thinking about what they’re trading away.

The speed you’re measuring isn’t the speed that matters

When your team…

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

First, Agree on the Tradeoffs (Jade Rubick)

tl;dr: Most technical disagreements stall because people are arguing positions, not evaluating tradeoffs. Force at least three options (teams almost never explore the solution space enough on their own), get everyone to explicitly agree on the tradeoffs between them, then decide. Aligning on tradeoffs shifts people from advocacy mode into analytical mode and you get genuine buy-in almost for free because people feel heard before the decision is even made.

Read more