Stop memorizing STAR for behavioral interviews. Start selecting better stories.

Gilad Naor

Gilad Naor created Management Deltas, a leadership method that helps software managers and Staff+ engineers accelerate their careers and ace behavioral interviews. He spent nearly 20 years in tech as an engineering leader at Meta, Amazon, and startups, where he led multiple engineering teams and interviewed dozens of Staff+ and Manager+ candidates. Since 2022, Gilad has coached 250+ leaders, helping them land roles at Big Tech companies. At Meta and Amazon, he sat through countless interview debriefs - seeing firsthand what separates strong candidates from those who get a "no hire" on behavioral. He now teaches engineering managers how to level up through cohort-based classes and 1:1 coaching. Ready to accelerate your leadership career? If you want to accelerate your career, then explore his leadership resources and frameworks here.

"Why don't you tell me about a time you received constructive feedback?"

Simple question. Staff-level candidate. Should be easy.

"I was leading development of a new service at Amazon. Tight deadlines, exciting technical challenges. My role included end-to-end delivery and then transition to the next project. I prioritized shipping the core functionality. Built it, tested it, launched it. The service worked technically. But during my next review cycle, my manager flagged it. The team struggled without proper docs. The handoff left gaps. I learned to treat documentation and handoff as first-class requirements, not afterthoughts. Now I add them as explicit tasks in the backlog from day one when planning projects."

Perfect CARL format. Clear context. Specific actions. Measurable results. Concrete learning.

Rejected on behavioral.

Why? Because at senior+ levels, your story selection matters more than your story structure.

Why listen to me

Hi, I'm Gilad. I was an engineering leader at Amazon and Meta. In my role I interviewed dozens of Staff+ and Manager candidates. I attended debriefs and candidate review discussions. Since 2022, I've coached hundreds of senior engineers aiming for a Big Tech role.

After seeing what works and what doesn't, I noticed one major disconnect. Most candidates are stressed about their delivery. Will their answer be clear? Concise? Follow the STAR or CARL format?

After hundreds of sessions, my intuition told me that delivery is important, but not nearly as important as everyone fears. Looking at the data, I could see it clearly. The number 1 reason for a no hire? The wrong story, not the delivery. Choosing the right story is more important than how you tell it.

The data

The team at interviewing.io pulled some numbers to back up the assertion that story selection matters. They looked at their corpus of behavioral mock interviews and specifically pulled the interviews where the candidate passed but where the interviewer recommended a down-level.

Below are the mistakes that caused those candidates to get down-leveled. As you can see, all of these mistakes have to do with story selection and content rather than story delivery.

The problem with STAR/CARL at senior+ levels

There's an interesting challenge that compounds and grows the more senior you are. The more successful in your career you are, the bigger this challenge. You have plenty of experience. Lots of stories to choose from.

When you're aiming for a Staff+ position, you're not just trying to get a job. You're aiming for a job at a specific level. Because you have the breadth of experience, not all of your stories will showcase the right leveling signal.

Say you're applying for a Senior Manager role. There's a good chance you had to support a "low performer" on your team multiple times. Which story do you choose to tell in the interview? Here's the deal. The story that you choose has to show a delta from a line-manager. Your story must be something that most line-managers rarely face. Otherwise, the interviewer is left with a blank. They have nothing to go with, no data to help them make the M1 versus M2 call. Instead, talk about the staff engineer that micro-managed their team or the engineering manager that avoided hard conversations.

Or let’s say you're going for a Staff Engineer role. You tell the interviewer about the time you coached a junior engineer on how to structure their PRs and how that made them more productive. Sure, great. But the interviewer sees most Senior Engineers do the same every week. Instead, show how you coached a new TL and helped them become a leader that their team follows.

The 5-step pre-compute algorithm

Over the years, I developed a 5-step algorithm to help clients prepare for their interviews. Here's how you can use it for your upcoming loop.

Step 1: Brainstorm stories (with dimensions)

Start by understanding what the company values. Research the dimensions they care about - not just the generic leadership principles, but the real signals they look for:

• Handling ambiguity
• Managing conflict
• Driving cross-team initiatives
• Technical trade-offs at scale
• Stakeholder management
• Dealing with failure

Some companies publish these. Others hide them. All of them have patterns you can spot in the job description. If you're not sure where to start, look at your current company's promotion criteria for the target level.

Now brainstorm. Use these dimensions as prompts to pull stories from your memory. Open a doc and brain dump everything. Stuck? Use AI to ask you guiding questions. "Tell me about a time you had to coordinate across five teams." Let it pull stories out of you.

Don't filter yet. Just collect. You want quantity first - aim for 20-30 stories across all dimensions.

Step 2: Identify scope

Now analyze each story. For each one, figure out what was hard. Was it the ambiguity level? The coordination challenge? The cross-functional dependencies? The number of humans you had to align? The technical complexity? The timeline pressure?

Write it down in short bullets. What made this story actually difficult? What obstacles did you face? What constraints made it challenging?

Be specific. "Tight deadline" isn't enough. "3-week deadline for a typically 3-month project during Q4 code freeze" tells me the real challenge.

Step 3: Gather evidence

This is the step most candidates skip - and it's why their stories fall flat. You need proof points. Hard data that demonstrates the challenge was real and your impact was meaningful.

For each story, collect:

Quantitative evidence:

• Number of teams involved (7 teams across 3 orgs)
• Number of people affected (45 engineers, 200+ stakeholders)
• Timeline pressures (6 weeks vs. typical 6 months)
• Budget or revenue impact ($2.3M cost savings)
• Performance improvements (reduced latency from 800ms to 50ms at P99)
• Scale metrics (handling 10M requests/day)

Qualitative evidence:

• Seniority of stakeholders (VP-level approval required)
• Recognition received (CEO shout-out at all-hands)
• Customer testimonials ("This saved our Black Friday launch" - CTO of major retailer)
• Promotion or expanded scope afterward
• Industry impact (became the standard approach adopted by 3 other companies)
• Failure recovery (project initially rejected by 4 teams, eventually adopted company-wide)

Organizational evidence:

• First time attempted at the company
• Changed company policy or process
• Became a case study for future projects
• Influenced roadmap for multiple quarters

Go back to your old emails, Slack messages, performance reviews, design docs. Find the receipts. If you can't find evidence, the story might not be as impactful as you remember.

Step 4: Filter ruthlessly

Now comes the hard part. Any story that doesn't have both clear challenges AND compelling evidence at the target level? Delete it. Be brutal.

That story where you debugged a tricky issue? Unless it saved the company millions or unblocked 50 engineers, delete. That time you helped onboard a new teammate? Unless they became a tech lead in record time thanks to your mentorship, delete. That project where everything went smoothly? Delete, delete, delete.

Your evidence should make the interviewer think "Wow, that IS hard" or "I've never dealt with something that complex." If the challenge isn't crystal clear and backed by data at the right level, it doesn't make the cut. You should be left with 8-10 stories that truly showcase your target level.

Step 5: Craft your title

Every surviving story needs a compelling title. This is your hook. Your headline. The trailer that makes the interviewer lean in. Include a hint of the evidence in your title:

Instead of: "Let me tell you about a time I resolved conflict"

Try: "Let me tell you about the time two VPs wanted opposite architectures, and I had 3 weeks to align them"

Instead of: "Let me tell you about a project I led"

Try: "Let me tell you about leading a migration that 4 teams said was impossible - until we did it in 6 weeks"

Your title should tease both the challenge and hint at the evidence. Make them want to know more.

Before and after

Let's look at examples of running the 5-step Brainstorm-Scope-Evidence-Filter-Title algorithm.

Meta - Resolve conflict (Staff level)

The story that survived: two teams wanted different API designs

Amazon - Have backbone; disagree and commit (Staff level)

The story that survived: argued against killing a project I built

Your questions answered

What if I don't have enough evidence for my stories?

If you can't find evidence, you have three options:

1. Dig deeper. Check old emails, performance reviews, Slack archives. Ask former colleagues if they remember specifics. The evidence often exists; you've just forgotten it.
2. Start collecting now. For current and future projects, document the evidence as you go. Save that CEO email. Screenshot that customer testimonial. Track those metrics.
3. Acknowledge the gap. If you truly can't find evidence for Staff-level impact, you might not have Staff-level experience yet. That's valuable self-awareness. Go create those experiences.

How specific should my evidence be?

Very specific.

• "Large team" → "27 engineers across 4 teams"
• "Tight deadline" → "6 weeks during Q4 code freeze"
• "Senior stakeholder" → "VP of Product who initially opposed"
• "Big impact" → "$2.3M saved, 50% latency reduction" Specificity builds credibility. Round numbers feel made up. Precise numbers feel real.

Can I use the same story for multiple dimensions?

Yes, if you have different evidence for each dimension. A complex migration might show:

• Leadership: You aligned 15 engineers across 3 teams
• Handling ambiguity: Requirements changed 4 times mid-project
• Technical excellence: Achieved zero-downtime migration of 10TB Same story, different evidence, different framing. Use your title to signal which dimension you're addressing, and emphasize the relevant evidence in your answer.

What if my evidence is confidential?

Anonymize thoughtfully.

• "We saved my company 7-figures annually"
• "Reduced infrastructure costs by roughly 70%"
• Keep the impact clear while respecting confidentiality. The evidence's magnitude matters more than the specific company details.

How many stories do I actually need?

After filtering, you need 6-10 stories with strong evidence. Each should showcase different dimensions and challenges. Each should have 3-5 solid evidence points.

If you have fewer than 6 stories with compelling evidence, you have a gap. Either you need to remember more stories (go back to brainstorming) or you need to create more experiences before interviewing at that level.

Does this work for non-technical roles too?

Absolutely. The evidence just changes.

Product managers:

• Users impacted
• Revenue influenced
• Stakeholders aligned
• Time to market improved

Designers:

• User satisfaction scores
• A/B test results
• Design system adoption
• Cross-functional influence

Sales leaders:

• Deal size
• Sales cycle reduction
• Team performance lift
• Customer logos landed

The algorithm doesn't care about your function. It cares about proving your level with evidence.

What's next

You have the algorithm. Now go use it.

Block three hours this week. Open a doc. Run through the five steps. Spend extra time on Step 3 - Evidence. This is where most candidates shortchange themselves. Go find those receipts. Dig through old docs. Message former colleagues.

You'll be surprised how many of your "great stories" don't actually have compelling evidence. That's good. That's the point. Better to realize it now than in the interview room.

And look. If you get stuck on Step 1 and can't brainstorm enough stories... If you dig for evidence in Step 3 and come up empty... If nothing survives your Step 4 filter... That's valuable data.

It means you're not ready yet. Or you're targeting the wrong level. Or you need to go create better stories first. The algorithm doesn't lie. Evidence doesn't lie.

Want help running this for your next interview? Do anonymous mock behavioral interviews with Senior, Staff, or Principal engineers from FAANG and other top companies, and see exactly where you stack up.

See available times