This week’s newsletter is sponsored by Steady.

It’s time to quit doing work about work

55% of your engineering team’s time is spent doing busywork—chasing status updates, hunting for information and managing the mechanics of work.

All that work about work pulls devs out of flow, threatening focus, productivity and velocity.

Get the guide to Continuous Coordination and learn:

• The proven system that gives teams time back

• How to increase autonomy and accountability

• Advanced techniques for reducing coordination overhead

Get the guide

Thanks to Steady for sponsoring this newsletter. Let’s get back to this week’s thought!

Intro

Behavioral interviews play a significant part in the interview process. And in my opinion, the importance of behavioral interviews is just going to keep increasing as time goes on.

The reason?

The reason is that we are in the age of AI, where focus is a lot more on your soft skills, overall communication, and problem-solving. A lot less on your pure coding abilities.

Therefore, what problems you have solved (stories), what impact you had, and your overall skill to present your results and learnings in a compelling way → that’s going to be more and more important.

To help us be well prepared for behavioral interviews, especially for Big Tech roles, I had the pleasure of talking with Austen McDonald. In this article, I am sharing our full conversation and an in-depth overview of it.

Let’s introduce our guest author.

Introducing Austen McDonald

Austen McDonald is a former Senior Engineering Manager and Hiring Committee Chair at Meta, where he did over 1,000 interviews and trained 100s of interviewers, setting interview structures and picking questions.

Grab a copy of his best-selling book Mastering Behavioral Interviews, to get a complete prep system and learn how to land the roles that really matter.

My Full Conversation With Austen

You can watch/listen to the video below for the full conversation, or you can keep reading for the in-depth overview of our conversation.

Let’s start!

Behavioral Interview is Where Your Level Gets Determined

When I chaired Meta’s iOS + Android hiring committees and reviewed packets for staff-level engineers, I went directly to read the behavioral interview feedback.

System Design is also critical, of course, but I wanted to see immediately whether the candidate was solving staff-level problems and had the depth of experience and insight to be successful leading Meta’s highly autonomous engineering teams.

No staff-level scope there, no staff-level offer.

Let’s face it, there are only so many ways to invert a binary tree, and that’s not what senior engineers are for anyway.

We have AI for that now, and the scope of what’s required for senior engineers is only widening as we rely more on automated implementation.

Ownership, communication, the ability to handle ambiguity, conflict resolution skills, and leadership are what’s needed on teams. These are all assessed in the behavioral interview.

If you’re a senior/staff/principal+ engineer preparing for big tech interviews, the behavioral round isn’t something to squeeze in between LeetCode sessions. You need to actually prepare for it. It’s where your level gets determined.

Why Senior Engineers Underprepare for Behavioral Interviews

Most senior engineers underprepare for behavioral interviews:

• Their career has changed

A senior candidate might not have interviewed in a while, and during that time their scope has grown. They might be stuck in a more junior engineer mindset where behavioral interviews are more of a disqualifier than a critical part of the leveling process.

• Interviewers’ expectations have changed

As AI does more implementation work, more and more will be expected of our soft skills.

• Senior engineers have a lot of stories, and they are long

A senior engineer has more projects to talk about, so more emphasis needs to be placed on careful story selection. Also, senior engineers tend to have long projects that are then difficult to discuss. It takes effort to organize them and extract the most useful bits for interviewers.

• There are often multiple behavioral rounds

For Principal+ roles and managers, there are often multiple behavioral rounds: general culture fit, managing people, working with cross-functional partners, technical project retrospective, etc.

Every company’s process is different, but behavioral interviews provide the majority of the signal for these roles. For a principal role at a FAANG, compensation could be $1M+, so You Better Eat Your Wheaties before that interview.

The Real Way to Prepare: Decode-Select-Deliver

Most engineers approach behavioral prep like they approach coding prep. They find a list of “Top 50 Behavioral Interview Questions” or whatever and start rehearsing answers.

This is logical but wrong.

Behavioral interviews are about you and your actual experiences. You can’t practice your way through “Tell me about a time...” questions the same way you practice algorithms.

Instead, you need to be able to do three things in the interview:

Decode the question to understand what signal the interviewer is looking for. When someone asks “tell me about a time you had a conflict with your manager,” they’re not specifically interested in manager conflicts. They want to understand how you handle challenges with people in positions of authority.

Select the right story from your past that demonstrates the strongest signal. Often this means choosing the story with the largest scope, even if it doesn’t exactly match the literal question asked.

Deliver that story in a way that’s engaging and highlights your repeatable behaviors.

To do these three things well, you need a story catalog ready to go.

Building Your Story Catalog (Perfect Timing for Performance Reviews)

If you’re reading this in early 2026, you’re probably in the middle of writing your annual or semi-annual performance review. This is the perfect time to build your story catalog, even if you’re not actively interviewing.

Your story catalog should include 3-4 core stories that represent your high-water marks. These are the stories you’d tell a hiring manager if you only had a few minutes to demonstrate your capabilities.

For a staff engineer interview, these might be:

• A multi-year initiative you drove that involved coordinating across multiple teams

• A significant technical refactor with substantial business impact

• A situation where you resolved conflicts between teams with competing priorities

• A project where you handled significant ambiguity and made critical architectural decisions

One of my core stories from my time at Meta was how I transformed the iOS and Android recruiting pipelines to assess skills closer to the job, standardizing the coding and system design portions, enabling us to hit our hiring goals while helping to resolve some negative sentiment in the job market about Meta.

It shows strong evidence of ownership, communication, conflict resolution, data-driven decision making, and leadership.

Be sure to tag these core stories with what signal areas they demonstrate.

Beyond your core stories, you need additional stories covering any signal areas your core stories don’t touch on: scope, ownership, communication, growth, ambiguity, perseverance, conflict resolution, and leadership. Go through each signal area and identify at least one story that demonstrates your capabilities there.

To help those writing performance reviews, pay attention to the projects where you:

• Took initiative beyond your assigned work

• Solved a problem that seemed impossible

• Changed someone’s mind with data

• Made a mistake and learned from it

• Helped someone else grow

Those are your behavioral interview stories for when you need them.

Structuring Stories with CARL

Once you’ve identified your stories, you need to structure them effectively. Most people know STAR (Situation-Task-Action-Result), but I prefer CARL:

Context: The background of what was happening and why it mattered
Actions: The specific steps you took (plural, not singular)
Results: What changed and the impact you made
Learnings: What you learned or would do differently

The key difference is that CARL combines Situation and Task into Context, eliminating the mental energy wasted trying to separate them and it adds Learnings, which gives you a platform to demonstrate the depth of wisdom that separates senior engineers from less experienced ones.

When I interview someone who ends their story with a reflection like “This taught me to front-load alignment work before diving into implementation, which saved us three weeks on my next project,” I know I’m talking to someone who extracts transferable lessons from their experiences.

The Actions section deserves special attention. Interviewers are forecasters.

They’re looking at your past behaviors and predicting whether you’ll be successful in their organization. The more specific repeatable behaviors you can share, the more signal they get.

Don’t just say “I improved our deployment process.” Tell me:

• You analyzed deployment failures from the last two quarters

• You designed three different solutions and evaluated them against specific criteria

• You wrote a proposal and shared it with the team

• You got input from the platform team who would be affected

• You implemented the changes incrementally

• You measured the impact and shared results with stakeholders

Those are all repeatable behaviors. If you did them at your previous company, you’ll do them at the next one.

The Four Criteria for Selecting Stories

When an interviewer asks a question and you have multiple stories that could work from your Story Catalog, how do you choose?

Prioritize in this order:

1. Scope (most important)

Choose the project with the largest scope. This could mean:

• Breadth and variety of actions you took across the software development lifecycle

• Timescale (months vs. years)

• Technical and organizational complexity

• Business impact

2. Relevance

The story should naturally demonstrate the signal areas requested. But scope matters more than exact matching. If you’re asked about a conflict with your manager but your biggest conflict was actually with a product partner, tell the product partner story.

You still demonstrate conflict resolution with someone in a position of influence, but you showcase more of your repeatable behaviors. Time is short in interviews, so use your time to get out the largest scope stories.

3. Uniqueness

If you’ve already told a story in the interview, try to cover new ground with your next one. But don’t sacrifice scope or relevance for variety.

4. Recency

More recent stories carry more weight because they represent your current capabilities. But for senior candidates, a standout story from two years ago often beats a mediocre story from last month.

For more on story selection, including how to handle edge cases and different question types, check out the Select chapter in Mastering Behavioral Interviews.

Common Pitfalls That Cost Senior Engineers Offers

After coaching over 200 engineers through behavioral prep, many of them senior, staff, or principal level, I see the same mistakes repeatedly:

1. Choosing Stories with Insufficient Scope

You’re nervous in the interview. The interviewer asks “Tell me about a time you had a conflict with a manager.” You have an example that matches exactly, so you tell it. But it’s a small-scope conflict about whether to spend a day refactoring some code.

Meanwhile, you also resolved a major disagreement with a cross-team tech lead about resource planning for your teams. That’s the story you should tell. The interviewer is less interested in manager conflicts than they want to see how you handle high-stakes disagreements with leadership.

When you only have 45 minutes to demonstrate your capabilities, every minute spent on low-scope stories is a minute not spent showing you can operate at the target level.

2. Not Enough Repeatable Behaviors

Sometimes I hear stories just a little longer than, “We had this technical debt problem, so I proposed a refactor, we built it, and it improved our velocity.”

Great, sounds like an impactful project, but what did you do? You’re leaving out all the repeatable parts:

• How did you identify the technical debt was the root cause? Did you analyze bug patterns? Interview the team?

• How did you convince others to prioritize this? Did you quantify the cost? Present data in a meeting?

• How did you design the solution? Did you evaluate multiple approaches?

• How did you communicate the plan? Write a doc? Get feedback?

• How did you handle the implementation? Delegate tasks? Mentor junior engineers?

• How did you measure success?

• What were the follow-up actions, if any? And why were those the right ones?

These details are what the interviewer needs to assess whether you can repeat these behaviors at their company.

3. Verbosity Without Organization

Senior engineers, especially managers, like to talk. They’re good communicators. But I see people ramble through five-minute stories without clear structure, losing the interviewer’s attention.

For long stories, use signposting up front, a technique I call the Table of Contents. Say: “There were three particularly interesting parts to this project: how I identified and resolved conflicts around the approach, the technical challenges during implementation, and how we structured the rollout.” Then walk through each part with its own mini-CARL structure.

Think of it like slides in a presentation. When you change slides, the audience perks up and refocuses. Your signposts do the same thing.

4. Not Thinking Defensively

Senior roles involve high-stakes decisions. Hiring managers are actively looking for red flags. When you say “we had a lot of technical debt to deal with,” the interviewer might think: “Who created that debt? Weren’t you there? Why didn’t you prevent it?”

Always provide context that justifies the challenges you faced. “We’d made deliberate tradeoffs to ship quickly and secure a major customer, which left us with technical debt. Once we had product-market fit, I led the effort to address it strategically.”

5. Shifting Blame

When you say “we had to clean up another team’s feature they built in our code” or “my manager didn’t prioritize that,” you’re signaling that you don’t take ownership for outcomes. Senior engineers are expected to influence without authority, to work across team boundaries, and to drive results regardless of obstacles.

Instead: “We had competing priorities with the platform team. I gathered data on the impact to both teams and facilitated a conversation where we found a solution that worked for everyone.”

6. Unprocessed Emotional Baggage

Behavioral interviews require you to talk about your past, including difficult situations. If you’re still upset about that conflict with your tech lead or frustrated about that project that got cancelled, it will show. Senior interviewers have high EQ. They can detect when you haven’t processed something.

Before you use a story in an interview, make sure you’ve genuinely reflected on it and extracted learnings. If you can’t talk about it without frustration or resentment creeping into your tone, choose a different story.

Translating Your Experience for Big Tech

If you’re coming from a smaller company or a traditional company, you might worry that your stories don’t measure up. First off, this is everyone’s concern. I didn’t have big tech scale when I joined Meta, and neither do most people in their first big tech role.

But you can and should adjust how you talk about your experiences to resonate with big tech interviewers.

Scale: Speak Their Language

Big tech companies operate at massive scale: millions or billions of users, thousands of engineers, rapid iteration cycles, heavy investment in measurement and metrics.

Adjust your language to reflect familiarity with this environment:

Instead of: “I talked to Bill, the designer” Say: “I worked with the design team” (emphasize that you can work cross-functionally)

Instead of: “We improved our deployment process” Say: “I reduced deployment time from 2 hours to 15 minutes, saving our 20-person engineering team about 40 hours per month” (show data-driven decision making)

Instead of: “I built a new feature in our monolith” Say: “I built the feature in our usual monolith but I isolated it so it could be easily extracted in the future”

You’re not lying. You’re framing your experience in terms that signal you understand how big tech operates.

Culture: Emphasize the Right Values

Big tech companies have specific cultural values, even if they call them different things. When you tell your stories, emphasize:

Ownership: Don’t say “My manager assigned me this task in sprint planning.” Say “I noticed our deployment process was slowing us down, so I took initiative to redesign it.”

Data-driven thinking: Quantify everything you can, even if it’s an estimate. “About a 50% reduction” is better than “much faster.”

Systems thinking: Show you consider broader implications. “While implementing this feature, I designed the data model to support 10x user growth, even though we didn’t need it yet.”

Direct communication: Show you raise disagreements directly and resolve them with data. Avoiding difficult conversations or deferring to hierarchy signals weakness in big tech culture.

Rapid iteration: Emphasize experiences with quick shipping cycles, A/B testing, pilot programs, or hackathons.

Your Stories Are Better Than You Think

The biggest thing I tell people: your stories are better than you think they are. You probably had more impact, demonstrated more sophisticated thinking, and took more comprehensive actions than you’ve identified so far.

Spend time really thinking about all the pieces of the software development lifecycle where you demonstrated repeatable behaviors.

The identification phase, the alignment phase, the design phase, the implementation, the debugging, the rollout, the measurement, the follow-up. You did things in each of these phases that are worth talking about.

Many engineers coming from smaller or traditional companies think their stories aren’t good enough for big tech. That’s rarely true. Your stories do demonstrate repeatable behaviors that transfer across companies. You just need to find those behaviors and articulate them clearly.

Conclusion

The behavioral interview is where you get the roles that matter most. It’s where you demonstrate that you’re not just technically competent but that you can operate at the scope and complexity the company needs. It’s where leveling happens.

So spend time on preparation. Build your story catalog. Structure your stories with CARL. Practice telling them until you can deliver them confidently under interview pressure.

Last words

Special thanks to Austen for sharing his insights on this very important topic! Make sure to follow him on LinkedIn.

And also check out his comprehensive step-by-step system for preparing, from identifying your stories to practicing them to nailing the interview in his book Mastering Behavioral Interviews. It walks you through everything he learned from 1,000+ interviews and 200+ coaching sessions.

Also, subscribe to his newsletter for more insights on interviews!

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.