👋 Hey, it’s Stephane. I share lessons, and stories from my journey to help you lead with confidence as an Engineering Manager. To accelerate your growth see: AI Interview Coach | 50 Notion Templates | The EM’s Field Guide | CodeCrafters | Get Hired as an EM | 1:1 Coaching
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
You might also like some of my most popular posts:
See you in the next one,
~ Stephane