Speaking of which.

Relatable Brews #1

Software Engineer 2026 has never shipped harder.

If you’re mid prep (you should be), you can find all the published articles here, or start at the link below:

Here are 6 answers that work well for FAANG and other engineer interviews. Pick one or two that feel closest to something you’ve actually lived, then scroll down to find the full example below.

1. The over-engineering failure
   You built a system to handle 50M requests per second, the traffic never came.

2. The estimation failure
   You said yes to a timeline you couldn’t hit because you didn’t want to push back.

3. The shortcut failure
   You took a shortcut under pressure, and you/someone else paid for it.

4. The assumption failure
   You assumed alignment because nobody told you otherwise.

5. The communication failure
   You were right about the technical direction, but wrong about how you pushed for it.

6. The heads-down failure
   You went too deep on a problem and came up with the wrong thing.

By the way, if you’re a manager, your stories should look very different from this. This article is for you:

How to pick a story?

If you are not sure what kind of failure to pick? Know this - a good answer to this question is about your judgment, not your bad luck.

When asked “tell me about a mistake you made,” or “a time you failed,“ many engineers default to telling a post-mortem - the system broke, here’s the root cause, here’s the fix.

The problem here is that the interviewer needs to write something in the debrief about what you specifically learned and changed, and if you spend 80% of your time talking about a broken system, they don’t get that - and you don’t get the job or get down-leveled.

If your best story is “we missed a deadline” or “the system went down,” reframe it around the call you got wrong. “There was an outage” is an incident report. “I pushed to prod without a canary because I was confident it was low-risk” is a judgment failure.

Also, see my note in the end about “picking your level.”

IMPORTANT: Finally, avoid anything where you’re blaming someone else (even partially), anything involving HR or legal situations, and the classic “I’m too much of a perfectionist” - interviewers have heard that one approximately four hundred thousand times.

Sample Failure Answers for Engineers

Here are 6 carefully crafted answers that are about “judgement” vs “post-mortem”, and signal humility and agency (what interviewers are looking for) using my 5-point failure story arc.

1. The over-engineering story - “the perfect design no one asked for”

The failure: Your team needed a data pipeline for a single-market feature. You’d heard in a planning meeting that the product might expand to three more markets, so you designed for all four - configurable ingestion, multi-tenant storage, cross-region fallback, what not - ended up taking 10 weeks (pre-AI era) instead of 4. And… the expansion… got deprioritized in Q3.

The diagnosis: You’d made an architecture decision based on a hallway conversation, not a product commitment.

What you did: You brought it up with your manager before she had to ask. Walked her through where the extra weeks went, and why the assumptions behind them didn't hold up.

The lesson: Designing for a roadmap that doesn’t exist is speculation, not foresight.

What changed: You now ask one question before adding flexibility: “Is there a committed use case for this in the next two quarters?” If no, you design a clean extension point and move on. "Last quarter, my team needed a notification service. Someone suggested building it multi-channel from day one. I asked if we are going to add new channels in the next 6 months, and the answer was no. So we built for email only with a clean interface to swap later, and it took 3 weeks instead of 7."

If this reminds you of a time you built something technically elegant that nobody needed, that’s your story.

2. The estimation failure - “just say yes”

The failure: Your PM came to you with a tight launch date… it felt possible BUT IF everything went well. You know that never happens, but you still said yes. Not “yes if we cut scope” or “yes but here’s the risk,” just yes.

The diagnosis: You gave an unqualified yes because pushing back felt harder than absorbing the risk yourself. Most engineers confused being agreeable with being a good partner.

What you did: When things started slipping mid-project, you started working evenings and weekends to cover the gap instead of raising it. You shipped on time, but the last week's code needed two follow-up patches - and you you were cooked.

In the retro, you called it: “the timeline was wrong from the start, and I should have flagged the risks instead of absorbing them quietly.”

The lesson: Saying yes to an unrealistic timeline is deferring a hard conversation to a worse time. Your PM told you afterward: she'd rather hear an honest forecast than find out at the end that everything was at risk.

What changed: You now give estimates in ranges: best case, likely case, worst case, and say no when you have to “Last time a PM brought a tight deadline, I pushed back on scope. She cut two low-priority features, and the project shipped clean without anyone working on weekends.”

If this reminds you of a time you said yes when you should have said “yes, but,” that’s your story.

3. The shortcut story - “that TODO from 2013 is still in the codebase”

The failure: You were two weeks from launch, and still needed a data validation layer - about a week’s work. So you wrote a quick version with hardcoded rules and minimal error handling, plus a TODO that said “clean this up post-launch.” The TODO is still there. A new engineer traced a data quality bug back to your validation code after spending 2 days trying to debug the problem.

The diagnosis: You treated the deadline as permission to skip doing it right. The assumption was that you’d come back to it, but you couldn’t. No one can. There’s always a next deadline.

What you did: When your manager mentioned it in a 1-1, you paired with the new engineer on the rewrite, and owned the context gap that wasted her first two days.

The lesson: You didn’t save time, instead just moved it from your calendar to someone else’s. And she paid more for it, because she didn’t have the context you had when you wrote it.

What changed: You now file the cleanup ticket before the PR merges, with enough context that anyone can pick it up. “Post-launch cleanup” is a more than a prayer - it’s an approved line item in the project plan. “Last project, I blocked the launch checklist on the cleanup ticket being filed and estimated. Because it was already scoped and on someone’s board, it got done in week two post-launch instead of never.”

If this reminds you of a TODO that aged into permanent infrastructure, that’s your story.

By the way, I’ll recommend reading the below post before your interview - so you can avoid some potentially costly mistakes.

4. The assumption story - ”but we agreed on this”

The failure: You owned the backend for a feature launching with a partner team. The API contract was agreed in a doc, but in integration testing you found out they’d revised their frontend, and now needed fields you hadn’t built.

The diagnosis: We were building in parallel for 2 months with zero check-ins. The doc was supposed to be the source of truth, but nobody opened it after week one.

What you did: You got on a call with the other team’s lead that afternoon to map out exactly what had diverged. Then you spent the weekend patching things together and went to your manager on Monday to own the gap.

The lesson: A two-month-old doc is not a contract. While the onus is on both the team, if you haven’t talked to the other team’s engineers in weeks, you can’t take the upper hand and blame it on them.

What changed: Bi-weekly 30-minute sync with any dependency team on shared projects. “What changed on your side? Here’s what changed on ours.” “Last cross-team project, we had zero integration surprises. One of those syncs caught a schema change three weeks before it would have broken our integration tests.”

5. The communication failure - “won the argument, lost the room”

The failure: There were two approaches on the table for a service migration. In the design review, you spent 15 minutes systematically taking apart the recommended approach. Your manager’s feedback afterward: “kind of brutal in there.”

The diagnosis: You treated the review like a debate to win vs a decision to make together. While you were optimizing for the right answer, you completely ignored how you were delivering it.

What you did: Once you realized, you talked to the engineer directly about how you could have handled it differently. He appreciated it, but also transferred to another team 2 months later.

The lesson: Being right about the architecture doesn’t mean you handled the room well. The cost of “winning” a design review can be losing a collaborator you need for the next several projects.

What changed: You lead with questions now instead of counterpoints. “What happens to this under 10x load?” lets the room find the tradeoff together. “In my last design review, a junior engineer’s suggestion actually changed the final design. That doesn’t happen if people are afraid to speak up.”

6. The heads-down story - “building in a vaccum”

The failure: There was a reliability problem with a downstream dependency, and you picked it up. You had a strong opinion on how to fix it, so you went straight to building. A week and a half later, your tech lead pointed out in code review that the downstream team was moving to async next quarter, which would make most of what you’d built unnecessary. She’d mentioned it in a standup you’d half-listened to.

The diagnosis: You were confident you had enough context and didn’t bother checking before you started building.

What you did: You didn’t try to justify keeping the work. You went back, figured out what was actually salvageable, scrapped the rest, and built a thinner adapter that would be easy to swap when the async migration happened. You also went to her directly and said you should have checked in before going that deep.

The lesson: Going heads-down feels productive. But if you don’t check your assumptions against what other people know, you’re building in a vacuum.

What changed: You now do a 15-minute sanity check with your tech lead before starting anything that’ll take more than a few days. Just a “does this still make sense given what you know?” “Two months ago, one of those check-ins saved me from building a caching layer for a service that was getting deprecated. That fifteen-minute conversation saved me a week.”

If this reminds you of a time you went dark on a problem and resurfaced with the wrong answer, that’s your story. Works at any level. Junior engineers do it because they’re nervous about asking, senior engineers because they’re confident they already know.

Picking the right level

The level you’re interviewing for changes what counts.

At mid-level, the interviewer wants to see you can own a mistake and learn. Blast radius can be small - your work, your sprint.

At senior, the failure should touch something beyond your code. A timeline, a relationship, another person’s experience.

At Staff+, they’re scoring judgment. The failure should involve influence, technical strategy, or cross-org coordination.

I have a LOT more to say on this topic here, so find a cool infographic here:

New here? Start with Behavioral Interviews for EMs, Senior/Staff Engineers, PMs.

Most manager failures I’ve seen (mine included) fall into four buckets listed below. You only need one, maybe two for your interview prep. Pick what resonates most with your experience, and then scroll down fow full sample answers.

1. The talent retention failure
   You lost someone you should have kept.

2. The delegation failure
   You held too much yourself, and your team stopped taking on more independently.

3. The performance management failure
   You waited too long to address underperformance because you didn’t want to be “that manager.”

4. The relationship failure
   You were too unilateral with a cross-functional partner.

Why these failure stories work well for manager interviews?

These answers address the specific signals that interviewers are looking for. If you’re a manger and your answer to “tell me about a time you failed” says says “I underestimated the migration complexity and the project shipped six weeks late,” even if you nail the delivery - your debrief will likely say “limited leadership signal.“

The interviewer can’t tell from that story whether you’re a manager or a tech lead. On the other hand, a people failure - losing a high performer, mis-judging a coaching case, burning a cross-functional relationship - that can only happen to someone in the manager role. That’s the signal they’re hunting for.

If you're reading these and thinking 'I don't have any such management experience,' scroll to the end, I have an example for how to reframe a project failure so it still works for a manger interview.

If you’re not a manager, you might be on the wrong article. See the below instead for sample answers that work great for engineers:

Full sample answers for manager interviews

1. The talent retention failure

You lost someone you should have kept.

• Context: Senior engineer on your team, strong performer, been asking for more scope. She was your most reliable person on a high-visibility project

  Failure: You kept saying “next quarter” because the current project needed her where she was. “Next quarter” is sometimes manager-speak for “I don’t know yet, but the opportunity might reveal itself in time”

• Diagnosis: You treated development as something you’d get to, instead of something you actively build

• Action: She left for a team that gave her the tech lead role you’d been deferring. Two other engineers started asking about internal transfers within the month

• Learning: By the time “next quarter” arrives, your best people have already made their decision

• Behavior change: You now run quarterly growth conversations with every report, separate from perf, focused on what they want next and what you’re doing to get them there

If you’ve managed people for more than a year, you probably have one of these. Someone left and you know, honestly, you could have done more.

How to make your failure story land

Regardless of the story you choose, you need to signal 2 things in your answer: humility, and agency. You signal these by hitting 5 points: stating the failure, diagnosing it, showing what you did, naming the lesson, and proving the behavior changed. Check out the link below for a full breakdown on how to deliver this answer well.

2. The delegation failure

You held too much yourself, and your team stopped taking on more independently.

• Context: Running a team of 6-8 engineers across multiple workstreams, two of which had dependencies on partner teams

• Failure: You ran every cross-team sync yourself because you thought it was faster. You were also the only one talking to your skip-level about priorities. You’d built a team that worked great - as long as you were in every room

• Diagnosis: Your tech lead told you the team felt like they were “just building what you decided.” Your skip-level didn’t know any of your engineers by name

• Action: You’d optimized for speed and accidentally made yourself a single point of failure

• Learning: You were the bottleneck, and you’d built the bottleneck yourself

• Behavior change: You restructured so each engineer owned a workstream end-to-end, including the stakeholder relationship. Uncomfortable for a couple of weeks, but three people cited it as the most growth they’d had in their next perf cycle

  Join the Café Regulars community for career advice your skip-level can’t share. Free, always.

3. The performance management failure

You waited too long to address underperformance because you didn’t want to be “that manager.”

• Context: One engineer was consistently missing expectations - late on deliverables, shallow code reviews, your TL was picking up the slack - stretching to still meet deadlines

• Failure: You kept giving them “one more sprint” because they were trying, and you told yourself they’ll get there. Meanwhile, your strongest engineers were carrying their work on top of their own and starting to burn out

• Diagnosis: You were optimizing for your own emotional comfort, not the team’s. Being “nice” to one person meant being unfair to everyone else

• Action: By the time you started the formal performance conversation, your top performer had already told you in a 1:1 that she was “thinking about what’s next” - and she wasn’t talking about the roadmap

• Learning: Avoiding a hard performance conversation with one person can equate to creating a hard time for your whole team… they just might not be telling you about it

• Behavior change: You now have a 4-week rule. Another similar concern came up last quarter, and after you provided lightweight feedback for 3 weeks in a row, you had had the hard conversation in week four.

If you haven’t had to manage someone out, you could use a version where you gave tough feedback too late, or avoided a performance conversation because you were telling yourself it would resolve on its own. That said, most companies expect explicit performance management experience - so elevate your story a bit if you can.

4. The relationship failure

You were too unilateral with a cross-functional partner.

• Context: Shared initiative with a partner team, jointly funded, you owned the proposal

• Failure: You built the entire roadmap without looping in the partner team’s EM

• Diagnosis: The ideas were sound but the reaction was cold, they felt blindsided. Their EM escalated to your shared skip-level

• Action: Spent the next two months rebuilding trust you’d burned. The initiative started 3 weeks late due to ‘lack of alignment’

• Learning: Having the best doc doesn’t matter if the people who need to buy in feel blindsided by it

• Behavior change: You now co-author anything that touches another team’s resources before it ever hits a review, for example <talk about an instance where you actually did it>. Adds a week upfront, saves months of friction

What if I only have project failures stories?

If you only have a project failure, it can still work but reframe it around the leadership call you got wrong, not the timeline. “The project was understaffed“ is a generic project failure, but “I didn’t push back on scope when I knew my team was stretched“ is a management failure.

One thing to watch: make sure your “what I changed” is structural, not just effort. Not “I worked weekends to fix it“ but “I changed how I run the team.“ Other structural changes are - a new 1:1 cadence, a delegation model, a co-authoring rule etc.

One last thing…

One last thing, your story should come from your actual experiences, so you can tackle the follow up questions. However, you can start with the samples above, at least one or two of those should feel familiar. Pick what you think you can carry, fill in the specific person, the specific project, the specific conversation - and that’ll be your own unique story.

New here? Start with Behavioral Interviews for EMs, Senior/Staff Engineers, PMs.

At some point in your career, you get senior enough for your 1-1 feedback to start including what sounds like corporate jargon. Or as we call it, in professional circles and behind closed Slack channels, corporate bullshit - product sense, strategic thinking, and leadership judgment.

Then slowly the jargon creeps into your perf expectations, your 360 feedback. And eventually, painfully, your reasons not to promote.

Product Sense vs Strategic Thinking vs Leadership Judgement

The scope of what’s expected from engineers is expanding (e.g: Meta added product sense to their Engineering role guidelines). But the vocabulary being used to describe it is sloppy enough that you can do everything right and still miss because you optimized for the wrong word.

So the next time one of these shows up in your performance review, do yourself a favor and ask whether what they’re saying is also what they mean. Here’s a break down so you can aim at the right target.

What is product sense?

Product sense is figuring out what’s worth building and in what order.

It’s having a point of view on which problems actually matter, how users behave (not how you assume they behave), and what you’re willing to trade-off to solve the thing that matters most.

The person with strong product sense doesn’t just build what’s on the ticket. They’re the one who notices that users are exporting data to CSV because the product doesn’t have the dashboard they actually need, and then go build the dashboard

Here’s a detailed take on what is product sense, what’s hard about it for engineers, and how to build it.

When product sense is missing, you build something technically sound that probably still solves some problem, but it doesn’t move the needle on the metric that the business cares about. In other words, it’s wasted effort.

What is strategic thinking for engineers?

Strategic thinking gets thrown around a lot, and for engineers and new managers, it can feel especially vague. If often doesn’t mean writing a strategy doc. In practice, strategic thinking has three layers.

First, know the game. Connect the dots across your team’s goals, the org’s priorities, the competitive landscape, and what’s most likely to kill your product. You can’t think strategically about your work if you don’t know what game the company/org is playing.

Second, form an approach. Take what you learned in step one and turn it into a bet. If the competitive landscape says speed wins, your approach might be "identify a niche use case and iterate fast vs going broad." If your biggest risk is platform fragility, maybe you slow down and invest in durability. If there's a team two orgs over building something adjacent, maybe you partner deeply instead of building it yourself.

Once you have an approach, it should filter out everything else. Without an approach, you end up investing in onboarding and power-user features and internationalization all at once, and none of them move far enough to matter.

Third, actually follow it. If your approach is "iterate fast on a narrow use case," that should show up in every decision - cutting scope aggressively, picking scrappy over elegant because you need to learn before you invest, telling the partner team no when they want you to generalize your API.

Most teams agree on an approach in a planning meeting and spend the next quarter contradicting it because the day-to-day challenges feel more immediate.

So where does product sense end and strategic thinking begin?

Product sense tells you what to build. Strategic thinking tells you why that thing, in this context, right now. Product sense is “our users need a dashboard.” Strategic thinking is “we need the dashboard before we invest in the UI, because this year our focus is retention, not new growth.”

Leadership Judgment

Product sense and strategic thinking are about what to d and how to do. Judgment is about how you handle the human side of doing it - knowing what call to make, when to make it, and how much force to apply. Usually without enough information or clean data.

Timing - the same feedback lands completely differently on Monday after a launch versus Thursday after a reorg. Letting a team struggle through a hard problem instead of stepping in, because the learning matters more than the timeline. Escalating something early because you can see where it’s headed.

Calibration - knowing which battles need you to go to the mat and which ones you let go. Promoting someone your skip-level will question because you've seen something in the last two quarters that hasn't shown up in their metrics yet. Having a hard conversation at 70% intensity because the person is already shaky and you need them to hear it, not shut down.

Consistency - You can have sharp product sense and a solid strategy, but if your team doesn’t trust how you make calls, none of it compounds. That trust is built by people seeing a consistent logic behind your decisions, even the ones they initially disagreed with at first.

When judgment is missing, you see managers and leads who have the right read on the situation but blow the execution. They give the hard feedback on the wrong day, escalate something that needed one more week of data, fight for the right thing so aggressively that people stop wanting to work with them. The strategy was sound, the product sense was there. But the outcome still went sideways because the human part was off.

Meta’s IC6 engineers are now expected to “independently drive product decisions,” and it’s not just Meta. At PostHog and Linear, engineers own the roadmap, talk to users, and make product calls. The “product engineer” concept that used to be a startup thing is slowly becoming a core expectation across tech.

There's a navigator on the left if you want to skip ahead, but if you stay with me, we'll walk through these 3 questions in about 5 mins:

1. What product sense means

2. Where I see this getting hard for engineers, and

3. How to start building product sense without enrolling in a product strategy course

But why?

Because AI made writing code cheaper. When code is cheap, companies want engineers to justify their cost in more ways (and they want fewer engineers). Now this goes both ways, PMs are getting asked to ship code, build prototypes, or absorb marketing scope as well.

Andy Jassy was pretty direct when he told Amazon employees the company will need “fewer people doing some of the jobs that are being done today” and urged them to figure out how to “get more done with scrappier teams.”

So all engineers become PMs?

No. God, no. But everyone's scope will have to increase in some direction. Companies want more from you, and “product sense” is only one version of that more.

Meta is building teams with a 50:1 engineer-to-manager ratio, so some of those engineers will absorb what a manager used to do. Others will expand into data science, ML, production support, you name it. “Product engineer” is just one archetype, and it’s the one we’re talking about today.

What the hell is product sense for engineers?

Someone hands you a ticket: Add “export to CSV.”

An engineer without product sense builds the export, but an engineer with product sense asks: who’s exporting, what are they doing with the data, and is CSV actually what they need or are they copying it into a Google Sheet because we don’t have a dashboard?

That’s it. That’s the whole skill in miniature. In practice, someone with strong product sense can:

• Take a vague goal (“improve engagement”)

• Break it into meaningful user problems

• Propose solutions

• Anticipate risks

• Choose a direction with clear reasoning

If you’re interested, here’s a take on what your manager really means when they give you feedback on product sense vs strategic thinking.

Your shower thoughts ≠ product roadmap

The most common rookie mistake I see from both engineers and new PMs is that they assume they are the customer, and their wishlist is a product roadmap.

I’ve led multiple consumer-facing teams at Meta and Amazon, running experiments for millions of users, and I can tell you that new PMs often stumble in like toddlers at a construction site. MBA degree in the back pocket, hard hat on backwards, pointing at load-bearing walls going “have we thought about removing that?”

Sometimes they haven’t had their first 1:1 yet, and have insights about a product that a billion people use. Some very smart people spent years getting that product to a billion+ users, they were not sitting around waiting for your shower thought. Everyone gets humbled by their first A/B test.

Where this gets hard for engineers?

So why don't more engineers just… do this? Because product decisions come with three things that your IDE can't help you with:

1. Accountability with incomplete information. In engineering, the solution is provably correct or incorrect. In product, you’re choosing between options that all look reasonable, the data supports multiple directions, and the real answer only shows up six months later in retention. You still have to make the call now.

2. Constraints you can’t engineer around. Legal says no, design says it breaks the system language, but the VP wants it because a board member mentioned it. Product sense is a more than knowing what to build - it’s knowing what to build given everything you can’t control.

3. Politics. In any org of meaningful size, product decisions are negotiations. That other team whose metrics your feature will hurt? They have a VP too. Navigating that without caving or bulldozing is a skill, and most engineers haven’t had to develop it because someone else was doing it for them. That someone is increasingly not there.

How to build product sense? (no, you don’t need a course)

You don't need to become a PM, and you probably don't need a product strategy course either. But you do need a new habit. Experienced engineers and good managers tend do some of this instinctively, but if you’re not there yet…

Start here

Before you write code, answer three questions: What user pain does this reduce? How will we know it worked? What are we choosing not to do by doing this? If you can’t answer them, ask. The fact that you asked already puts you ahead of most engineers in the room.

In design reviews, argue from user outcomes. “This is a cleaner architecture” is an engineering argument. “This cuts the most common user flow from five steps to two” is a product argument.

After you ship, pull up the dashboard yourself. Don’t wait for the PM to present results in a review. The gap between “I built it” and “I built it and here’s what happened” is where product sense actually develops.

Build the muscle

Every annoying product behavior you encounter is a tradeoff someone made deliberately - start asking why. Read post-mortems for killed features, talk to real users instead of the one in your head, sit in reviews even when your code isn't on the table. The engineers who will develop product sense fastest would be the ones paying attention more broadly.

Learn faster, you have AI.

And yes - use AI to do all of this faster. Draft the one-pager in ten minutes with Claude or ChatGPT. Have it pull patterns from user feedback you’d never read manually. Ask it to stress-test your assumptions before you pitch them in a review. You’re already using AI to write code, use it to compress the learning loop.

Finally, if your manager told you to 'show more product sense' in your last perf review and you nodded while having no idea what that means differently from 'be more strategic' - I wrote a separate breakdown of how product sense differs from execution strategic thinking and leadership judgment - that’s here.

If you’re preparing for L5+ interviews at Amazon (SDE 2, Senior Engineer, other technical roles) this post will help you craft four stories that stretch across most of the 16 leadership principles, so you’re ready enough in 2-3 hours.

For non-technical roles, SDM, or Principal Engineer interviews, you’ll need to add another one or two stories.

I’ve been at big tech for about 10 years now and been on both sides of probably 200+ interviews. Just wrapped a cycle with EM offers from Meta, Netflix, and Airbnb, but also bombed at Doordash and Pinterest because I didn’t prep. Figured I’d write down what I picked up along the way while it’s fresh.

The Stories

Story 1: The Big Win (Ambiguous Problem → Strong Result)

Think of a project where you faced a complex, ambiguous problem, made a call with incomplete information, and delivered a measurable outcome. This is your workhorse story. It covers Dive Deep, Deliver Results, Bias for Action, and depending on how you tell it, Are Right A Lot, Hire and Develop the Best, and Customer Obsession.

When they ask a question about diving deep, lead with the investigation and root cause. When they ask “tell me about a time you delivered results despite obstacles,” you lead with the constraint and the outcome. “Tell me about a time you went above and beyond for a customer,” lead with customer impact. Same story, different entry point.

“We needed to improve product search relevance, but there was no consensus on whether the problem was the ranking model or the data pipeline. I ran a two-week analysis, found that 40% of our training data was stale, built the case to re-architect the ingestion layer, and shipped it in six weeks despite losing a key engineer mid-project. Relevance metrics improved 15% and customer contacts on search dropped by 20%.”

You’ll need to add a lot more flesh to the above, but this gives you an idea of what makes a good story in this category - ambiguity at the start, decisions in the middle, numbers at the end.

Now you need one where you looked bad.

Story 2: The Failure (Bad Call → Recovery → Learning)

Get a real one, where you were genuinely wrong. Not where circumstances conspired against you. “I underestimated the migration complexity and didn’t validate assumptions with the partner team early enough” is a failure story. “The requirements kept changing” is not (why) . This covers Ownership (you took responsibility) and Earn Trust (you were transparent about it).

“I scoped a data pipeline migration at three weeks. Didn’t consult the downstream team on their dependencies. The project took seven weeks. I learned my lesson, and rebuilt trust by running weekly syncs with their lead for the next project.”

Worth noting: Pick a real failure because the bar raiser has heard 400 fake failures. They can spot your “my failure is that I care too much” from a distance.

Story 3: The Disagreement

You pushed back on a technical decision, a product direction, or a process. You did it with data, not emotion. You either influenced the outcome or you committed fully to the direction that was chosen. This covers Have Backbone; Disagree and Commit and Earn Trust. If the disagreement was cross-team, it also covers influence without authority, which is a critical signal at senior+ levels (more on senior+ signals)

“Product wanted to launch at 60% model confidence, I showed data that below 85%, user trust metrics will tank. We compromised at 80% with a feedback loop. It wasn’t my ideal threshold, but I owned the execution completely.”

This one trips people up because they want to tell a story where they won the argument. That’s not what the LP is testing. It’s testing whether you can lose gracefully and still deliver.

Story 4: The Simplification

You noticed something broken outside your lane and fixed it anyway. That’s Invent and Simplify, Ownership, and Earn Trust in one story. These are weirdly easy to find because every team has at least one process that makes everyone quietly miserable.

“Our team spent 5 hours a week manually generating experiment reports. I built a self-serve dashboard in two sprints. Nobody asked me to. I just got tired of watching senior engineers waste time copy-pasting spreadsheets.”

How to structure them fast

For each story, write down three things:

1. Situation: write down two details - what was the context, what was at stake. These two are critical to mention upfront. You might get questions about the team structure and architecture in follow up questions. If you have time, think through them. But if not, wing them on the fly.

2. What you did and why: your specific action and why that approach over the alternatives. “I did X because Y, which meant trading off Z” is the sentence that gets written on the scorecard.

3. What was the outcome: give them a number. Revenue, latency, time saved, whatever you’ve got or can reliably fabricate. If you absolutely can’t quantify it, describe the observable change.

Spend 30 minutes per story. Write the bullets, don’t just think through them. The version in your head always sounds smoother than the version that comes out of your mouth for the first time under pressure.

That’s it, that’s four stories and about two hours of actual work. You’re ready enough.

“Tell me about a time you failed.”

You don’t want to look bad, so you find something safe. “We missed our deadline by a week, but recovered quickly.” And you can see it on the interviewer’s face, they’re writing “maybe not enough senior-level exposure” in their notes.

So next time you go bigger. “I misjudged the technical complexity, didn’t realize that we’d need to re-architect the entire data layer, and we were delayed by 6 weeks.” Now they’re looking at each other, “not sure if the candidate can lead a team on complex projects”

On the surface it seems that the problem with these answers is that they're too safe or too honest. However, the real problem is that they're both incomplete. Ideally, your answer should cover the following 5 points:

1. State the failure clearly

2. Explain what caused it

3. Show what you did when you realized it

4. Share the lesson you extracted

5. Show how your behavior changed afterward

I’ve been at big tech for 10+ years now and been on both sides of probably 200+ interviews. Just wrapped a cycle with EM offers from Meta, Netflix, and Airbnb, but also bombed at Doordash and Pinterest because I didn’t prep. Figured I’d write down what I picked up along the way while it’s fresh. This is a part of my question-by-question behavioral interview series, see all the questions here.

If you’re looking for sample answers, see my related posts:

The five-part story arc (with examples)

You can ensure that you answer is complete with humility + agency with the following 5 point arc:

Honest failure: This is where humility starts, higher stakes for higher roles. You state the actual failure, in words you’d use talking to a friend. “I misjudged the technical complexity, didn’t realize that we’d need to re-architect the data layer, and we were delayed by 6 weeks.”

Clear diagnosis: You’re showing you root caused and now understand the specific decision or assumption that made the failure preventable. “I assumed the other team understood our timeline because it was in the doc. I never confirmed they’d actually read it.”

Decisive action: This is where agency kicks in. What did you do when you realized things were going sideways? “I called an emergency sync with all three blocked teams, reset expectations with my director, and we shipped a stripped-down version in two weeks.”

Extracted learning: The actual thing you now understand that you didn’t before. You had a gap, and now you can name it. “I learned that being technically right isn’t enough. I was so focused on proving my approach would work that I forgot to make room for others to shape it.”

Demonstrated improvement: Proof you’re not the same person who made that mistake “In my most recent 360, three different peers mentioned that I make them feel heard before pushing for a direction. That’s not something anyone would have said about me before.”

If you skip any one of these, the interviewer will feel that something’s off.

Example Story

We were building a new personalization feature that required ingesting customer behavioral signals from across multiple surfaces. I knew privacy review was part of the process, but I treated it like a checkbox for the endgame.

Six weeks later, when the Privacy team reviewed our architecture, they flagged that the way we were storing and joining customer signals didn’t meet their data isolation requirements. The fix required reworking how we partitioned and retained data, which meant re-opening design decisions with a dependency team.

We slipped by a month, and my team had to redo work they’d already shipped. The marketing partners waiting on us lost a launch window.

The privacy team’s concerns were completely reasonable. If I’d brought them in during early design, we would have designed around the constraints from the start instead of retrofitting around them later.

What I changed: I now start a privacy review thread as soon as there’s early alignment on a project and the design is largely approved - before any engineering work begins. It adds maybe a week to the front of the timeline, and has saved significantly more on every project since.

Where most stories break

I have seen most failure stories break in two places:

They skip ownership. The failure gets framed as bad luck, bad timing, bad circumstances, or the story stays safely in “we” language throughout (read more about the “we” problem). The interviewer’s thinking: When things go wrong here, are they going to blame the team / leadership / organization? At Amazon and Netflix, where individual accountability is baked into the culture, this can be disqualifying on its own.

They skip demonstrated improvement. The candidate articulates a great lesson - “I learned that stakeholder alignment is critical” - but ended there with any mention of anything changing for real. The interviewer’s wondering: Nice philosophy. But did it actually happen? Evidence of behavioral change does weighs much more than stated intentions.

Other FAQ

Is it okay to talk about a big failure in interviews?

Yes - bigger is usually better, especially for senior roles. That said, the bulk of your answer should be diagnosis, learning, and how you operate differently now. A lot of candidates slip into a blow by blow account of the what happened (oh and then the Privacy Program Manager said this, so I responded with that) - this is where you lose the interview. The interviewer moves on to the next question and you miss signaling skills they wanted to see.

Is it okay to mention that a dependency team made a mistake, or that leadership changed requirements?

Even if it’s true, it doesn’t produce the signals interviewers are scoring for. The moment you point outward, the interviewer stops hearing accountability. Name what you missed, what you would do differently. That’s the only part that moves the needle in a debrief.

How recent should the failure be?

Ideally within the last 1-2 years and relevant to the level you’re interviewing for - shows a growth mindset.

What if I haven’t had a major failure?

It can feel like that, especially if you’re looking for “catastrophes”. A failure doesn’t have to be a dramatic implosions, it could be a judgment call that cost the team a few weeks, or a relationship you let drift until it became a blocker, or a process gap you didn't see until it bit you. A project that shipped late, a hire that didn't work out, a technical bet that didn't pay off - all of these count.

Sometimes, a story that feels "too small" when you first think of it often ends up being the strongest once you unpack what you actually learned. Try running your stories through the the five-part arc, and send me a message if you still think you don’t have a story.

What Meta, Amazon, Netflix, Google, and other tech companies look for?

There is a whole range of variations that companies use for this question.

There are no strong company-specific patterns, but Google often takes the project lens: “Tell me about a time you had to change course after realizing your approach was wrong?”, Meta asks “What’s your biggest mistake as a manager?”, Amazon usually frames it through Ownership: “Tell me about a decision you made with limited data that turned out to be wrong?”, while Netflix wants “A hiring decision you regret”

At the mid IC level, the interviewers want to see you can learn from mistakes. For senior, staff, principal, and management roles, they’re evaluating whether you can own failures that affected teams, timelines, strategy; how you root caused the problem, and how your judgment improved after impact.

For EMs, this is often the a heavily weighted behavioral question in the loop. I’ve seen entire interview panels turn on it multiple times.

Different companies use different frameworks (Netflix Culture Memo, Googliness, Amazon Leadership Principles), but they are all screening for the same two traits: humility and agency.

Humility: you recognize when you’re wrong and own it without making it someone else’s fault.

Agency: you act, you learn, you change.

A failure story missing either one doesn’t land, no matter how smooth you sound.

Now audit yours

Do this now - take your strongest failure story, walk it through the five parts, and identify the weakest one.

That’s where your prep time should go before polishing language or delivery.

When you read the feedback, it’s almost always about scope of work. Their scope is substantial, but that’s not what comes through in their answers.

Your interviewer doesn’t know the complexity of your org chart or how many hurdles you cross everyday. They only hear what you choose to surface in a few stories.

In practice, level is inferred indirectly - from the kinds of decisions you describe, how you talk about ownership, how wide your influence shows up, and whether you surface real trade-offs and business impact.

If those signals doesn’t come through clearly, the default assumption is L5 scope, even when your technical rounds are stellar.

I’ve been at big tech for 10+ years now and been on both sides of probably 200+ interviews. Just wrapped a cycle with EM offers from Meta, Netflix, and Airbnb, but also bombed at Doordash and Pinterest because I didn’t prep. Figured I’d write down what I picked up along the way while it’s fresh. This is a part of my seniority signals series.

The infographic below breaks down the exact signals interviewers consciously or subconsciously use to infer level. It gives you a quick way to sanity-check whether your stories are actually signaling L6/L7, or downgrading you quietly.

How interviewers actually infer your level from your stories

If you prefer reading on a desktop, download the 2-column version from my google drive.

Hopefully this makes it clearer how interviewers are reading between the lines in your stories. Small shifts in what you surface can materially change how you get calibrated.

If you’re prepping for behavioral interviews (EM, Senior/Staff Engineer, PM) at Meta, Amazon, Netflix, Google, or similar companies, this is the stuff I wish someone handed me upfront.

I’ve cleared every FAANG loop over the years (some multiple times), and spent 10+ years at multiple big tech companies - leading teams, getting promoted, and sitting on both sides of 200+ interviews. I’m not here to inspire you. This is practical notes, patterns, and examples you can build on.

If you’ve already done some prep and are here to polish, jump to Common Mistakes, if you’re in early stages of prep, start with Company-Specific Prep or Question Prep. If you haven’t done this before, start with Foundations.

Common Mistakes

• Why your interviews don’t sound like senior-level work (even if your job is)

• Behavioral interview mistakes that get you down-leveled - Part 1

• Part 2 — [Coming Soon]

Company-Specific Prep

• 4 Stories. That’s all you need for your Amazon loop.

• Meta EM Loop — [Coming Soon]

• Netflix Culture Memo — [Coming Soon]

• Googliness - [Coming Soon]

Question Prep

• The “Failure Question” Ends More Interviews Than Any Other

  • Tell me about a time you failed - 4 sample answers for managers

  • 6 Sample Answers For ‘Tell Me About a Time You Failed’ - for Software Engineers

• Tell me about a project you’re proud of - [Coming Soon]

• Tell me about a disagreement with your manager or peer — [Coming Soon]

• Tell me about a time you influenced without authority — [Coming Soon]

Foundational

• A simple structure (not STAR) to build answers fast without sounding rehearsed — [Coming Soon]

• I Spent $1,500 on Mock Interviews for FAANG Offers. 80% Was Useless.

If you read just the first two sections above, you’ll already be ahead of most candidates.

You need to ace your technical rounds, but that’s more of a minimum qualification these days. It’s the behavioral rounds that decide whether you get the offer, and at what level.

“I don’t know why I got rejected, the interviews went great.” Heard that one before? Everyone thinks behavioral is the easy part. They're right. But it's also the easiest part to fuck up.

I’ve been on both sides of 200+ interviews at FAANG companies, and and just wrapped up an interview cycle with EM offers from Meta, Netflix, and Airbnb (and bombing without prep at Doordash and Pinterest). Figured I'd write down what I’ve learned while it's fresh.

I don’t know how many parts I’ll end up writing, but this is Part 1: Foundational Mistakes, and this will be a part of the common interview mistakes series. I’ll cover two killers today:

→ Hiding behind “we”

→ Ending stories without real learning

What else should I cover in future posts? Thinking story construction, signaling seniority, showing growth - but open to suggestions.

The Foundational Mistakes

1. The “we” problem

“We struggled with prioritization across teams.”
“The project faced scope creep issues.”
“Our stakeholders weren’t aligned.”

The Problem

Every time you say “we/our/the team/the project” to explain a challenge or action, the interviewer mentally adds a note: What did this person actually do?

Candidates think they’re being humble, or they’re being a team player. The interviewer thinks they’re either dodging accountability or taking credit without contribution. I’ve seen people lead entire programs and get down-leveled because they couldn’t articulate what they did versus what happened around them.

What to Do Instead

Dodging Accountability
Instead of “we struggled with prioritization” -> “I underestimated the Ads team dependency and deprioritized their integration. It cost us 3 weeks when they changed their API.”

Taking Credit Without Contribution
Instead of “the team decided to use microservices” -> “I pushed for microservices over a monolith because I’d seen two similar projects bog down in deployment conflicts”

When “we” is Fine

“We shipped the feature” is fine for outcomes when you have explained your decisions first. For example: “I chose to cut scope on the admin panel so we could ship the feature on time” - shows your decision.

New here? Start here → Behavioral Interviews

2. Fumbling the landing

“We shipped on time and hit our metrics.”
“The project was successful, customers loved it.”

And then...
...nothing?
Let’s call this... premature... evacuation.
You finished, but nobody’s satisfied.

Every story needs a landing - what you took away, what you’d do differently. That’s the ending.

I use “What did you learn?” as one of my bullshit detectors. When someone describes a hard problem and can’t articulate what they’d do differently now, it’s a red flag. They either don’t learn from experience (alarm!), or they were probably just there when things happened, but weren’t the main character.

Wall Posters vs Learnings

• “Proactive Communication Is Important”

• “I Learned To Plan Better”

These are wall posters, not learnings. They’re what “you’re supposed” to say, but tell me nothing about how you actually work differently now.

How To Phrase Learnings

Phrase your learning as something I could observe if I watched you work.

“After that production incident, I changed how I do design reviews. Now I have a checklist for common failure modes. I was able to catch a latency issue using this in Q3.”

“I used to think my job was shipping features. That escalation taught me my job is managing risk. I now front load legal/privacy review early in the project. I got pushback from my engineers when I tried to do this recently in Project Banana, but turned out to be the right decision when the legal team objected to using a crawler…”

Notice the structure:

1. What I believed before (could be implicit)

2. What happened that challenged it

3. What I do differently now - specific and observable

4. Proof it works

If your “learning” doesn’t change a concrete behavior you can point to, you didn’t learn, you just had an experience.

The simple takeaway is…

Behavioral interviews are about one thing: do you sound like someone who operates at the level you’re interviewing for?

The two mistakes we discussed in this post make you sound like someone things happened to, not someone who made things happen. That’s how you walk out thinking “that went great” and get the rejection email three days later.

Spent ~$1.5k on interview coaching across HelloInterview and Prepfully. Should you do the same? Here’s my take on what coaching is actually worth, and what’s a waste of money:

New here? Start here → Behavioral Interviews

The Value Hierarchy

Coding mocks

• Paid for one session preparing for Meta coding.

• Could’ve skipped it entirely and wouldn’t have made any difference to anything.

Recommendation: Nearly worthless.

System Design Mocks

• Unless you’re completely making up your tech design experience, or have interview anxiety, you don’t really need a mock session for system design.

• HelloInterview has excellent design prep materials and everything you need - the 35$ (as of Jan 2026) is totally worth it.

• I took a session each at Prepfully and HelloInterview, mostly out of curiosity. Both were ok - but didn’t add significant incremental value to my preparation.

Recommendation: Skip the mocks, use the resources.

People Management Questions

• These are mostly about how do you hire/fire/handle X.

• These questions have very standard answers.

• If you have been a manager for 2 yrs at a regular tech company, you know this game already.

• If not, ask Claude to run a mock for you. You might still fail (in-experience is hard to hide), but at least you won’t have spent the money.

Recommendation: Not worth paying $200+/hour for this

Where Coaching Actually Helped

Tech Talk / Presentation Rounds

• What are these? Multiple companies have tech talks rounds for EMs (possibly other roles as well). They ask you to present something, and then grill you on it.

• Interview Coach told me to expect X format. I thought of verifying with the recruiter, and glad I did - his info info was 3 years stale.

• Plot twist: I did book another session for Netflix, and the mock helped me realize that my chosen project wasn’t conveying the right signals. The domain complexity was drowning the tech complexity. I changed the project last minute, and aced the interview.

Recommendation: Hire a coach if you have a serious tech presentation interview. Ask for: 1) A signal audit (are you showcasing the technical complexity and leadership signals), and 2) Follow-up question prep (where will they drill you?). They’ll catch what you’re too close to see.

Behavioral Culture Fit Rounds

• Engineering Manager / Product Manager / Program Manager loops squeeze in behavior questions in at least 3-4 rounds

• You need 15-20 stories in your bank

• Here’s what I learned either from coaches or self-reflection post interviews:

  • Weak stories - did not signal enough of what the interviewers are looking for

  • Stories where I might be looking bad

  • Stories that answered the question but didn’t sell me enough

  • Duplicate-ish stories - I realized while the stories were different, they were not providing new points to the interviewer

• The main value: external audit of your story bank before you’re in the room. A weak story in a mock-review is embarrassing. In an interview it’s disqualifying.

Recommendation: Highest ROI by far

HelloInterview vs Prepfully

HelloInterview

• Random coach matching (you get who you get)

• More expensive

• Outside of mocks, great platform and study resources

Strategy: Use platform for prep, skip coaching sessions

Prepfully

• Choose your specific coach

• Review their background, read their profile

• Usually cheaper per session

Strategy: pick coaches strategically for your target companies

What I’d do differently:

• $0 on coding mocks

• $0 on system design mocks (use HelloInterview platform content only)

• 1 session for project presentation mock

• 1-2 sessions for behavioral coaching to audit story bank

• Use Prepfully, choose coaches carefully

• Verify everything a coach tells you about process/format with your recruiter

In the end, I scored an incremental +$250K on my current TC ($450K), so the money was worth it. But 80% of what I bought was waste.

The 20% that mattered - catching 3-4 weak stories probably added $200k+ to my offer mix. I was able to negotiate my very first offer (before the other offers lined up) because the feedback was strong - said the recruiter. If you’re spending on interview prep, spend it there. Everything else is google-able, claude-able, self-learnable, or your recruiter knows better than any coach.