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 a state-management migration like the one in R4, 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.