Behavioural at staff level

The tell they listen for is the pronoun. A senior story is full of "I". A staff story has "I" for the decision and the persuasion, and "we" for the execution — because at that level you are judged on outcomes you could not have produced alone.

Structure the answer around how you built the case, not how right you were:

1. The problem, in their currency. Not "the code is messy" but "we are spending two days a sprint on this and here is the measurement."
2. The evidence. A prototype, a benchmark, an incident count. Data beats opinion, and a working demo beats data.
3. The objections you had to answer — and who raised them. Naming a real sceptic and how you won them over is the most convincing part of any story like this.
4. The outcome, measured.

Your standards story fits this exactly. So does the Redux to Zustand migration, if you tell it as a persuasion problem rather than a technical one: you had to convince a team to accept a migration cost, and the honest naming of what was lost is what made it credible.

The shape that lands: the decision → the reasoning that was sound at the time → the signal that contradicted it → how long you took to accept it → what you did → the rule you now carry.

The part most candidates skip is the fourth: how long you took to accept it. Being honest that you defended it for two weeks before the evidence became undeniable is more credible than a story where you updated instantly, and it demonstrates the thing they are actually probing — whether ego gets in the way of the data.

Have a real framework and a real example. The framework:

• Whose problem is it, and how many people have it? One loud customer is not a product signal.
• What is the cost of being wrong in each direction? A reversible decision made quickly beats a perfect decision made slowly; an irreversible one deserves the opposite treatment.
• What does it cost to own, not to build? The build is a few weeks; the maintenance, the on-call surface and the migration cost when it needs replacing are the real bill. This is the argument you already make about not adding a message broker.
• What does it stop us doing? Opportunity cost is the argument that actually persuades product people, because it is in their language.

Then a concrete story: something you argued against, and either won or lost. Losing is fine — "I lost that argument, we built it, and it was retired eighteen months later" is a strong ending, as long as you do not tell it smugly.

The factors, in the order that actually decides it:

• Is it core to what makes the business different? Build the differentiator, buy everything else. You do not build an auth provider; you might build a matching engine.
• Total cost of ownership, not licence cost. Engineer-months to build, plus maintenance forever, plus the on-call burden, versus a subscription. Engineers systematically underestimate the "forever" column by a large factor.
• Time to value. Six months of building is six months of not shipping the thing customers asked for.
• Exit cost. How hard is it to leave the vendor in two years? A wrapper layer at the boundary makes a buy decision reversible, and that is often what makes it acceptable.
• Compliance and data residency, which sometimes decide it outright regardless of the rest.

Say the default out loud: buy, unless it is core or the vendor cost scales badly with your growth. Then give the exception you have actually lived.

• Tell me about a project you killed. Or should have. What was the sunk-cost pressure and how did you handle it?
• How do you drive a migration across teams that do not report to you? The real answer involves making the new path easier than the old one, not writing a policy.
• How do you set technical direction without becoming a bottleneck? Written design docs, a review forum, and defaults that make the right thing easy.
• Tell me about mentoring someone senior, not a junior. Different skill entirely — it is peer coaching, not teaching.
• How do you handle disagreeing with a director or a founder? Privately first, with data, and with a clear statement of what you will do if the decision goes the other way.
• Describe an incident that crossed team boundaries. Who coordinated? How was the post-mortem run and what actually changed?
• How do you balance technical debt against features? The error-budget framing from the observability card is the strongest answer — it turns the argument into arithmetic.
• What is your approach to on-call and to alert quality?
• How do you evaluate a new technology before adopting it? A time-boxed spike with predefined success criteria written down before starting, so the decision is not made by whoever is most excited.
• How do you hire? What do you look for, what do you screen out, how do you run your part of a loop.
• What is the largest scope you have owned, honestly? Answer truthfully. Overclaiming scope is trivially exposed by two follow-up questions, and it ends the round.