Behavioural and culture fit fundamentals

Whether your past behaviour predicts your future behaviour on their team, which is a narrower and less personal question than candidates assume. The premise of the format is that what somebody did under real constraints, with real colleagues, is the best available evidence for what they will do again, and that self-description is nearly worthless by comparison. So the interviewer is listening for a specific decision you made, the information you had when you made it, and what happened as a result. Likeability is not the criterion and is mostly a confound the format exists to suppress: a well-run round scores against written competencies, and a candidate who is charming with no evidence attached loses to one who is dull and specific. The practical consequence is that your preparation is a set of remembered events, not a set of adjectives.

Because a hypothetical measures your taste and your vocabulary, and the round is trying to measure your behaviour. "I would sit down with them and understand their perspective" is what everybody says, costs nothing to say, and is unfalsifiable — there is no follow-up that can distinguish someone who does it from someone who has read about it. A real event has friction in it: the thing you said that did not work, the week you left it, the colleague who was still annoyed afterwards. Interviewers are trained to notice the tense, because the slide from "I did" into "I would" is the commonest tell that a candidate has run out of examples and is improvising a policy instead. If you genuinely have no example, say so and offer the nearest real one rather than inventing a philosophy.

The same question answered twice, and the conversion is mechanical once you see where the tense slips.

Q: "How do you handle it when a colleague isn't pulling their weight?"

HYPOTHETICAL - what most candidates say
  "I'd speak to them directly first rather than going to the manager.
   I'd try to understand whether something else was going on, and I'd
   focus on the impact on the team rather than making it personal. If
   nothing changed I'd escalate."

  Score: no evidence. Every sentence is a policy. Nothing here could
  be untrue. The interviewer records "no example offered".

CONVERSION - three questions to ask yourself
  1  When did this last actually happen to me?
     -> Q1 last year, the reconciliation service, with Tom.
  2  What did I specifically say, in words?
     -> "Your two tickets have been in review for nine days and the
        release is blocked on them. What's in the way?"
  3  What happened next, and what did it cost?
     -> He was covering an on-call rota nobody had reassigned. Fixed
        in a day. Release slipped four days, not two weeks.

REAL - the same values, now with evidence
  "Last year on the reconciliation work, Tom's two tickets sat in
   review for nine days and the release was blocked. I went to him
   before I went to our lead, and I asked what was in the way rather
   than why he was late. It turned out he'd inherited an on-call rota
   nobody had reassigned when Anya left, so he was firefighting every
   afternoon. I took the rota for a week and we split his tickets.
   The release slipped four days. I also told our lead about the rota,
   because that was the actual defect and it would have hit whoever
   was next."

The conversion works because the values in the hypothetical were fine. What was missing was the event, and the three questions recover it: an occasion, a sentence you actually said, and a consequence. Nothing about your judgement had to change.

The detail that makes the real version score is that the diagnosis was wrong at the start. The candidate went in thinking somebody was slow and found a structural problem, which is evidence of asking before concluding — a thing the hypothetical merely claimed. Interviewers weight surprises heavily, because a story where the candidate's first assumption held is usually a story that has been smoothed.

The last two sentences do the work that separates a competent answer from a senior one. Fixing the instance is expected; naming the rota as the real defect and reporting it upward shows that you think past your own unblocking. Note that it is also the part that could not have been invented, because it is specific to this company and this departure.

Answers are not scored on the first telling. They are scored on what survives three follow-ups.

flowchart TD
    A[Candidate tells the story<br/>90 seconds] --> B[Probe one<br/>what exactly did you say]
    B --> C[Probe two<br/>what did they say back]
    C --> D[Probe three<br/>what would you do differently]
    D --> E{Detail holds up}
    E -->|yes| F[Recorded as evidence<br/>competency scored with a quote]
    E -->|no| G[Recorded as a rehearsed narrative<br/>no evidence scored]

The three probes are not escalating scepticism, they are three different measurements. The first asks for words in quotation marks, because a candidate who was present can usually reconstruct roughly what they said and a candidate describing a summary cannot. The second asks for the other person's response, which is where invented stories collapse: made-up colleagues either agree immediately or are cartoonishly obstructive, whereas real ones say something partly reasonable.

The third probe is doing something else again. By that point the interviewer believes the event happened and wants to know whether you have thought about it since. "Nothing, it worked out" is a weak answer even after a success, because every real project contains a decision worth revisiting.

The practical preparation this implies is depth over breadth. Six stories you can survive three probes on beat fifteen you can only summarise, and the rehearsal that matters is not the ninety-second version — it is being able to answer what the other person said, who else was in the room, what the dates were, and what you would change.

Candidates lose here in a specific way worth naming: they answer the probe with more of the summary, at a higher volume. When asked what you said, say what you said. If you cannot remember, saying "I can't quote it, but the substance was that the deadline was at risk and I wanted to descope rather than add people" costs you nothing and reads as honest.

Evidence, ideally quoted, mapped to named competencies decided before you walked in. A well-run round has three or four of them — ownership, collaboration, dealing with ambiguity, handling disagreement — each with a written description of what a strong and a weak answer looks like, and the interviewer's job is to record what you said against those lines rather than to form an impression. This matters to you because it tells you what to supply: a fact somebody can write down. An answer with no quotable specifics leaves the scorecard blank, and a blank scorecard is scored as no evidence rather than as neutral, which is why pleasant, fluent, unspecific candidates are rejected with debriefs that say "did not get much".

Four recur almost everywhere, whatever the company calls them. Ownership, which is whether you carry a thing past the point where it stops being formally yours. Collaboration and conflict, which is what you do when a competent person disagrees with you. Dealing with ambiguity, which is how you move when the requirements, the priority or the owner is undefined. And self-awareness, which is whether you can describe your own mistakes and the feedback you have received without either defending or performing. Senior loops add influence and judgement about people. The reason this list is worth knowing is that it tells you how to build a story portfolio: not one story per question you have heard, but a small set of events rich enough to answer across these four.

It matters less than candidates fear and in a different way than they think. Structure exists precisely to stop the round measuring similarity to the interviewer, and the better the process the less warmth buys you. What does count is a narrow, defensible version of the same thing: whether the interviewer believes colleagues can raise a problem with you, disagree with you, and give you bad news. That is not charm — it is demonstrated in how you talk about people who were wrong, whether you concede a point during the interview itself, and whether any of your stories contain a colleague who improved your thinking. Contempt for a former colleague or manager is the version of unlikeability that actually costs offers, because it predicts how you will describe this team later.

Because two independent samples of the same behaviour are worth more than one, and because a story told twice is a consistency check. Interviewers in a well-run loop write their scores before the debrief, so two people asking about conflict is not duplication, it is calibration. It is also how invented examples are caught, since the details drift on the second telling in ways they do not for a real event. What follows for you is that you should not fear repeating a story across rounds — you should fear telling it differently. If you are asked something a previous interviewer covered, say so, offer to give the short version and then a second example, and let them choose. That reads as organised, not as evasive.

Situation, task, action, result: set the scene, say what you specifically had to do, describe what you did, state what happened. It is useful because it forces the last part, which candidates otherwise omit. Its failure is a predictable imbalance — most answers are ninety per cent situation, because the setup is the comfortable part and the action requires admitting what you personally chose. The result then arrives as a sentence like "it went well", or the answer runs out of time before it. The second weakness is that STAR has no slot for reflection, so an answer can be complete by the format and still not say what you learned. The fix is not a different acronym so much as a time budget: if more than a quarter of your answer is scene-setting, cut it.

Written out at length first, because you cannot compress a story you have not told once properly.

Q: "Tell me about a time you disagreed with a technical decision."

SITUATION - 2 sentences, no more
  "In early 2025 we were splitting a monolith. Our tech lead decided
   the new order service would own its own copy of customer data,
   synced by a nightly job."

TASK - what was specifically mine
  "I owned the checkout path, which read customer address data on
   every order. So the correctness of that sync was my problem to live
   with, and I thought a nightly job was wrong for it."

ACTION - the bulk of the answer, in the first person
  "I disagreed in the design review but I didn't win it there, mostly
   because I argued about the pattern rather than the consequence. So
   afterwards I did two things.

   First I got a number. I pulled six months of address changes and
   found 340 changes a month, about 40 of which were followed by an
   order within 24 hours. So roughly 40 orders a month would ship to
   a stale address, and we were doing 12,000 - a 0.3% failure rate on
   the one thing customers notice.

   Then I went to the tech lead privately, before raising it again in
   a group. I said I thought I'd argued it badly and here was the
   actual cost, and I asked what constraint had pushed him to nightly
   sync. It turned out to be a real one: he didn't want checkout to
   have a synchronous dependency on the customer service, which I
   agreed with.

   So the disagreement stopped being sync versus async and became a
   third option we hadn't considered - keep the local copy, but have
   customer service publish change events so it updated in seconds
   rather than overnight. I wrote a one-page comparison of the three
   options with the 40-orders number in it, and he took it to the
   next review himself."

RESULT - a number, and the honest limits of it
  "We shipped the event-driven version. Mis-shipped orders from stale
   addresses ran at 2 to 4 a month afterwards rather than the ~40 we'd
   have had - I'm inferring the counterfactual, we never ran the
   nightly version in production. It cost about a week more than the
   nightly job would have."

REFLECTION - what changed in how I work
  "What I got wrong was the first attempt. I argued about the design
   pattern in front of six people, which made it a contest. Now I go
   and find the cost first, and I take it to the owner privately
   before I take it to a room."

Four things make this score, and each is a thing candidates omit. The candidate lost the first round and says so, which is what makes the rest credible — an answer where the disagreement was won immediately usually means the disagreement was not real. The number is small and specific rather than impressive, and it is honest about being an inference.

The turn in the middle is the actual substance. Asking what constraint produced the decision you dislike converted a two-option fight into a third option, and that is the behaviour the competency is looking for. The alternative version of this story — persistence until the lead gave in — scores much worse for the same outcome.

The private conversation before the public one is the detail that separates seniority levels here. So is giving the tech lead the one-pager to present himself, which the candidate does not editorialise about and does not need to.

The reflection is narrow enough to be believable. "I now find the cost first and take it to the owner privately" is a changed practice you can be probed on. "I learned to communicate better" is the same sentence with the evidence removed.

The long version is for preparation. This is the version you actually deliver.

"Splitting a monolith in 2025. Our tech lead decided the new order
 service would keep its own copy of customer data, synced nightly. I
 owned checkout, which read addresses on every order, so I'd be living
 with that staleness.

 I argued against it in the design review and lost - fairly, because I
 argued about the pattern instead of the cost. So I went and got the
 cost: 340 address changes a month, about 40 followed by an order
 within a day. That's 40 orders a month shipping to a stale address.

 Then I went to him privately rather than reopening it in a meeting,
 said I'd made the case badly, and asked what constraint had pushed
 him to nightly. It was that he didn't want checkout synchronously
 depending on the customer service - which I agreed with. That gave us
 a third option: keep the local copy, but update it from change events
 instead of a nightly batch. I wrote a one-page comparison and he took
 it to the next review himself.

 We shipped that. Stale-address mis-ships ran at 2 to 4 a month
 instead of the 40 we'd have had, and it cost about a week extra.

 The thing I changed: find the cost before the argument, and take it
 to the owner privately before a room."

Word count: 230. Spoken: about 95 seconds.

What was cut from the long version, and why it was safe to cut
  - the 12,000 orders and the 0.3% figure. One number lands; three
    invite arithmetic instead of listening. Keep them for the probe.
  - the second design review, the names of the other options, the
    week-by-week sequence. All recoverable if asked.
  - every clause explaining why the disagreement mattered. The story
    demonstrates that; saying it as well reads as justification.

The compression rule is one number, one turn, one lesson. Everything cut is still available, and holding it back is an advantage rather than a loss: an answer that has already spent every detail leaves the interviewer nothing to probe, and probing is how evidence gets recorded.

Ninety seconds to two minutes is the target because that is roughly the point where an interviewer stops taking notes and starts waiting. Four-minute answers are the commonest structural failure in the round, and they are almost never caused by too much action — they are caused by scene-setting and by narrating the parts where nothing was decided.

The other discipline is to stop deliberately. Ending with the lesson and then being quiet invites the follow-up you want, whereas trailing off into "so, yeah, that was that one" transfers the awkwardness to the interviewer, who will usually rescue you by changing the subject — which is how a good story gets scored as thin.

Situation, behaviour, impact: name the occasion, describe the observable behaviour without interpreting it, then state the effect it had. It is a feedback frame rather than a storytelling frame, so it is the right structure when the answer is about something you said to somebody else — feedback you gave, a conversation about underperformance, a peer whose conduct was a problem. Its value in an interview is that it demonstrates the discipline of separating behaviour from character, which is the thing that makes feedback survivable. "He was dismissive" is an interpretation and invites an argument about intent; "he moved to the next agenda item without asking a question" is a fact. An interviewer hearing the second version learns that you can raise a problem without escalating it.

Challenge, action, result — STAR with the situation and task collapsed into one. It exists because the two front sections of STAR overlap heavily and are where answers bloat, so merging them enforces the time budget the format keeps failing at. Use it when the context is quick to state or already known, which covers most questions in a round after the first. There is a fifth-letter variant, CARL, that adds learning, and the acronym you choose matters far less than whether the answer contains all four things: enough context to make the decision legible, a decision that was yours, an outcome, and a reflection. Treat these as a checklist you run afterwards rather than a script you speak, since an audibly acronym-shaped answer is its own tell.

Ninety seconds to two minutes for the main telling, then stop. That is roughly two hundred to three hundred spoken words, which is much less than candidates expect and is the reason the compressed version has to be rehearsed. The constraint is not the interviewer's patience so much as the structure of the round: they have three or four competencies to evidence in forty-five minutes, and an answer that runs five minutes costs a question that would have given you another chance to score. The failure in the other direction is real but rarer — a thirty-second answer with no action in it forces the interviewer to extract the story with six questions, and some will simply move on. Aim to be probed, not to be complete.

The proportions are the whole technique, and they are almost the inverse of what comes naturally.

flowchart LR
    A[Context<br/>15 seconds] --> B[What was specifically yours<br/>15 seconds]
    B --> C[What you did and decided<br/>50 seconds]
    C --> D[Result with one number<br/>15 seconds]
    D --> E[What you changed after<br/>10 seconds]
    E --> F[Stop and wait<br/>silence is fine]

Fifty seconds of the hundred and five go to what you did. That ratio is the single highest-leverage change most candidates can make, because untrained answers spend forty or fifty seconds on context — the org chart, the product, why the project existed — and then compress the decisions into "so we fixed it". Context is only there to make your decision legible. If a detail does not change how the interviewer reads your choice, cut it.

The second box exists because "we" hides in the setup. Fifteen seconds saying what was yours as distinct from the team's is what lets the rest of the answer use "I" without sounding like a credit grab, and its absence is why so many answers are unscoreable — the interviewer cannot tell which parts you did.

The result box is short on purpose. One number, and if you have no number, one observable change; more than that and the answer turns into a defence of the measurement.

The last box is the part nobody rehearses. Stopping cleanly and letting three seconds pass signals that the answer is finished and hands the turn back. If you have miscalibrated, the interviewer will tell you by what they ask next, which is better information than any amount of self-monitoring while you talk.

The same event told twice. The difference is not fluency.

Q: "Tell me about a time you had to work under a tight deadline."

WEAK
  "We had a really tight deadline on a big client integration last
   year. The requirements kept changing and we were understaffed,
   which made it very challenging. I'm quite good under pressure, so I
   just put my head down and worked a lot of extra hours. There was a
   lot of back and forth with the client. In the end we got it over
   the line and the client was happy, which was a great outcome for
   the team. It taught me a lot about time management."

REWRITE
  "A client integration due 30 September, agreed before I joined the
   project. Three weeks out I mapped what was left and it was about
   five weeks of work for the two of us.

   I decided not to ask for more people, because onboarding someone
   into the mapping logic would have cost more than it returned. What
   I did instead was take the scope list to the client's project
   manager and split it: the four endpoints they needed to go live,
   and the three that could follow in October. I brought that as two
   options with dates rather than as a problem.

   They took it. We shipped the four on 28 September and the rest on
   17 October. I worked two late weeks, which I'd count as a cost
   rather than a virtue - the real fix was that nobody had checked the
   remaining scope against the date until three weeks out.

   Since then I re-baseline the estimate against the date every
   fortnight and send it to whoever owns the deadline, even when it's
   fine. That's the habit I took out of it."

WHAT CHANGED
  vague time      -> a date, and "three weeks out"
  "understaffed"  -> a decision not to add people, with a reason
  "worked hard"   -> a scope conversation with a named counterparty
  "client happy"  -> two dates, one of them a slip, stated plainly
  "learned a lot" -> a fortnightly re-baseline, probeable
  hours as virtue -> hours as a symptom of a planning failure
  no "I" anywhere -> "I decided", "I brought", "I'd count"

The weak answer is not badly delivered and that is the point. It is fluent, positive, and contains no evidence: no date, no decision, no number, and nobody in it but the candidate and an undifferentiated client. An interviewer cannot write a single line on a scorecard from it.

The rewrite is the same event with the decisions put back. The load-bearing sentence is the one about not adding people, because it shows a trade-off considered and rejected for a stated reason — a choice, which is the unit behavioural rounds are built from.

Treating the late weeks as a cost rather than a virtue is the move that most distinguishes senior candidates. Heroism reads as a planning failure to anybody who has managed delivery, and volunteering that reading gets you the credit for the insight instead of the follow-up question.

Notice that the rewrite admits a slip. Three endpoints landed seventeen days late, and saying so makes the four that landed on time believable. Answers where everything succeeded are the ones that get probed hardest.

You do not need a story per question. You need five events rich enough to be cut in several directions.

A tick means the story answers that question type honestly - without
being bent to fit, which interviewers notice.

                            cnf  fail  infl  dead  ambg  fdbk  mind  team
--------------------------  ---  ----  ----  ----  ----  ----  ----  ----
1  Address-sync argument     X          X                       X
   lost the review, found
   the cost, third option

2  Payments migration        X    X           X                       X
   slipped 6 weeks, I had
   under-scoped the tests

3  Legacy report rewrite          X          X    X                   X
   I pushed for a rewrite,
   was wrong, we patched

4  On-call noise project               X          X          X    X
   nobody owned it, no
   mandate, 60% fewer pages

5  Mentoring a struggling                                    X        X
   joiner - hard feedback
   given and received

cnf conflict   fail failure   infl influence   dead deadline
ambg ambiguity  fdbk feedback  mind changed my mind  team teamwork

Coverage check
  every column has at least two candidate stories -> good
  story 2 covers four columns -> your strongest asset, prepare it
    to three probes deep in each direction
  fdbk column is thin, and both entries are the same relationship
    -> the gap to go and find another example for

The portfolio is built by listing events, not by listing questions. Five to seven real projects or incidents, each with a decision of yours in it, will cover almost any behavioural round; the work is deciding which facet of each one to lead with for a given question.

The coverage check is the part that makes this a preparation tool rather than a diagram. A thin column is a predictable failure — you will be asked about feedback, you will reach for the one story you have, and if the interviewer probes past it you have nothing. Finding a second example is a twenty-minute job if you do it before the interview.

The multi-column story is worth disproportionate preparation. A single event you can tell four different ways, each with the same dates and colleagues, is also the most robust to probing, because you genuinely remember it. That robustness is what the third follow-up is testing for.

One warning the table makes visible: a tick is only honest if the story really does answer that question. Bending the address-sync story into a deadline answer means the details will not support the framing, and the mismatch between what was asked and what you told is itself recorded — usually as "did not answer the question".

Pick the one where your decision is closest to the competency being asked about, not the one with the most impressive outcome. A candidate asked about conflict who tells the story of a large successful launch has answered a different question, and the interviewer must either re-ask or score nothing. The second criterion is proximity in time and detail: a recent event you remember well survives probing, and a five-year-old one you have smoothed into an anecdote does not. The third is scale honesty — reaching for the biggest thing you were adjacent to usually produces an answer where your own part is thin, which reads worse than a small story you clearly owned. When two stories fit, choose the one where you were partly wrong, because it is harder to fake and scores higher.

Most real work has no metric attached. That is not a licence to say the outcome was positive.

Situation: you cleaned up a flaky test suite. Nobody tracked anything.

DO NOT SAY
  "It significantly improved developer productivity and morale."
  Unfalsifiable, and the interviewer discounts the whole answer.

SUBSTITUTE 1 - a count you can reconstruct
  "I went back through the CI history: we were re-running builds
   about 15 times a week because of four tests. After, it was
   under 2. I counted the re-runs, I didn't measure time saved."
  Works because the number is a fact you retrieved, and you say
  where its edges are.

SUBSTITUTE 2 - a behaviour that changed
  "Before, the team's habit was to hit rerun without reading the
   failure. Two months later people were opening failures again,
   and we caught a real race condition that would have been
   reruns before."
  Works because a changed behaviour is observable by others and
  is exactly what the interviewer wants to know about impact.

SUBSTITUTE 3 - a decision it unblocked
  "It was a precondition for turning on merge-on-green, which we
   couldn't do while the suite was flaky. That shipped a month
   later and is still on."
  Works because someone else's decision depending on your work is
  third-party evidence, which beats any self-reported figure.

THE SENTENCE THAT MAKES ANY OF THEM SAFE
  "We didn't instrument this, so this is a count I reconstructed
   afterwards rather than a measurement."

The three substitutes are a count, a changed behaviour, and an unblocked decision. All three are checkable in principle and none requires that anybody was running a dashboard, which is why they beat both the vague claim and the invented percentage.

The invented percentage is the specific trap here. Candidates who have absorbed "quantify your results" produce figures like "improved performance by forty per cent", and the follow-up — measured how, over what baseline, at what percentile — is where the answer dies. A number you cannot defend is worse than no number, because it converts a scoring question into a credibility question.

Naming the limits of your own figure is not a weakness and reads as unusual rigour. Interviewers hear inflated numbers all day; a candidate who says "this is a count, not a measurement" is telling them how much weight to put on it, which is what an honest engineer does with data generally.

The last resort, when none of the three is available, is the counterfactual stated as one: what would have happened otherwise, flagged explicitly as an inference. "We never ran the other version, so I'm inferring" costs nothing and keeps the answer honest.

"We" for what the team did, "I" for what you decided, and the interviewer needs the second to score you at all. Answers given entirely in "we" are the most common reason a competent candidate gets no evidence recorded: the interviewer cannot tell whether you led the work, contributed to it, or were in the room, and absence of signal is scored as absence rather than as neutral. The over-correction is also a real failure — an answer entirely in "I" about work that obviously involved eight people reads as either inaccurate or as somebody who takes credit, which is disqualifying for anything senior. The pattern that works is first person for decisions and third person for outcomes: I argued for the phased cutover, I got the numbers, we shipped it, and Priya found the flaw that saved us.

With a real disagreement, in private, about a consequence rather than a preference, and with what happened after the decision. The structure that scores is: what they decided, what you thought the cost was and how you found out, that you raised it with them directly before raising it anywhere else, what you asked them that you did not know, and then the outcome — including the case where you lost. The two failure modes are opposite. A story where you had no real disagreement, or where it was resolved by them immediately agreeing, tells the interviewer you avoid these conversations or are inventing one. A story where you escalated, went around them, or relitigated the decision afterwards answers the question and fails the round.

You lose the option of settling it by authority, so the answer has to be about evidence and framing rather than persistence. What interviewers listen for is whether you asked what they knew that you did not — senior engineers usually hold context about a past failure, a commercial constraint or an operational history that makes an apparently poor choice reasonable, and a candidate who never sought it looks like somebody who mistakes seniority for stubbornness. The second thing is proportionality: whether you judged the disagreement worth spending on at all. The strongest version of this answer names something you noticed, checked, and then dropped because the cost of being right was higher than the cost of the decision, which is a judgement candidates rarely think to volunteer.

The point of this answer is that the argument stopped being about opinions, and the mechanism by which it stopped.

Q: "Tell me about a technical disagreement and how it was resolved."

THE DISAGREEMENT
  Me: the read latency problem is the N+1 in the order listing.
  Senior colleague: it's the database, we need a read replica.
  Both plausible. Neither of us had evidence. Two days of meetings.

WHAT I DID INSTEAD OF ARGUING AGAIN
  Proposed a cheap experiment we both agreed to in advance:
    "If I add query logging to staging for a day and the listing
     endpoint issues more than 50 queries per request, it's the
     N+1. If it's under 10 and p95 database time is over 200ms,
     it's capacity and you're right. Either way we stop arguing
     on Thursday."

  Agreeing the interpretation BEFORE the data is the whole move.
  Otherwise whoever loses disputes the measurement.

WHAT THE DATA SAID
  p95 request: 1.9s
  queries per request: 312   <- 1 listing + 1 per order + 2 per line
  p95 single-query time: 3ms  <- database was not the problem
  fix: one join plus a batch load -> p95 240ms, 2 days' work

  A read replica would have made 312 fast queries slightly faster
  and cost us replication lag on a page that had just been written
  to. It would also have looked like it worked for a quarter.

HOW IT ENDED, INCLUDING THE PART THAT MATTERED
  He was right about the trend - traffic was growing and we did add
  a replica two quarters later, for reporting. I said that out loud
  in the review, because he'd been arguing about next year and I'd
  been arguing about this week. We were answering different
  questions.

The experiment is the answer, not the fix. Two engineers with plausible hypotheses and no data will argue indefinitely, and the behaviour worth demonstrating is converting the disagreement into a measurement cheap enough that nobody has to concede first.

Agreeing the interpretation in advance is the detail that makes it work and the one candidates leave out. If you collect the data first and then propose what it means, the losing side disputes the methodology, and you have added a second argument to the first. A pre-agreed threshold with a date removes that.

The closing paragraph is what lifts this from a story about being right. Saying publicly that the other person was right about a different timescale costs nothing and buys the ability to disagree with him again next month. An answer that ends with the candidate vindicated and the colleague silent is a worse answer for an identical technical outcome.

The observation about the replica making the problem invisible for a quarter is worth including because it is the interesting engineering content. It shows you thought about what the wrong fix would have looked like, which is a different and higher-scoring thing than knowing what the right one was.

One where you disagreed properly, then committed visibly, and then did something about the risk that did not involve being right in public later. Concretely: you made the case once with the cost attached, you asked what you were missing, the decision went the other way, you said so to your own team without editorialising about it, and you wrote down your reasoning and the specific thing you would watch. If the risk then materialised, you raised it as new information rather than as vindication. Interviewers are largely testing for the absence of two behaviours here — quiet non-compliance, and the "as I said at the time" that follows a bad outcome. The sentence that closes this answer well is that you would rather have a decision you disagree with than an open one.

The most valuable conflict story most candidates have and the one they never tell.

Q: "Tell me about a time you disagreed with someone and you were wrong."

WHAT I THOUGHT
  "Our reporting service was a 40,000-line legacy thing with no
   tests. I wanted to rewrite it. I made the case twice: the code
   was unmaintainable, every change took a fortnight, and I thought
   a rewrite was six to eight weeks."

WHO DISAGREED AND WHAT THEY SAID
  "Our principal engineer said no, and her argument was that we
   didn't know what the code did. Not that we couldn't read it -
   that nobody knew which of the 60 reports were still used, by
   whom, and with what edge cases baked in over nine years."

WHAT I DID - the part I'd do the same way
  "I asked to test it cheaply rather than arguing again. We added
   access logging to the report endpoints for a month."

WHAT THE MONTH SHOWED
  "41 of the 60 reports had been run in 30 days. Eleven had a
   single user. Three were pulled by a finance process I'd never
   heard of, on a schedule, and one of those was in an audit
   pack. My six-to-eight week estimate had assumed about 20
   reports and no external consumers. It was wrong by a lot -
   realistically a quarter, with a compliance risk attached."

WHAT WE DID INSTEAD
  "We deleted the 19 unused reports, put a characterisation test
   around the finance three, and refactored incrementally behind
   the existing interface. Change lead time went from about two
   weeks to three days over five months. No rewrite."

WHAT I ACTUALLY LEARNED - narrow
  "My estimate was wrong because I'd estimated the code and not
   the consumers. I now start any replacement question with who
   is calling this, before how hard is it to rebuild. And the
   thing she did that I've copied: she didn't overrule me, she
   proposed a month of data."

The answer is credible because the candidate was wrong in a specific, quantified way — an estimate off by roughly a factor of three, for a nameable reason — rather than wrong in the vague, characterful way that failure answers usually offer.

The second thing it demonstrates is that being wrong was discovered rather than conceded. The candidate proposed the measurement that disproved their own position, which is the behaviour the competency is actually about, and it is why this scores higher than a story where the candidate was right.

Praising the principal engineer's method, and saying it has been copied, is the part that turns a failure into evidence of learning from people. It also answers, in passing, a question about mentorship and about how you handle seniority.

The lesson is narrow enough to be probeable: consumers before code, on any replacement question. Compare the version most candidates give — "I learned to be more humble" — which describes a feeling rather than a practice and cannot be followed up.

It means arguing your case fully, then executing the decision that was made as if it were your own — including defending it to your own team and to people outside it. The fake version is verbal agreement with behavioural non-compliance: the work quietly deprioritised, the design followed to the letter in a way that guarantees failure, the reservations shared sideways with peers rather than with the decider. Interviewers probe for this by asking what you said to your team afterwards, and the answer that fails is any version of "I told them it wasn't my call". That sentence protects your own standing at the cost of the decision, and it is heard as exactly that. The credible version states the decision, states the reasoning as best you understand it, and names what you will watch.

Describe behaviour and impact, never character, and give the person their reasons. "He would rewrite my pull requests rather than comment on them" is a fact the interviewer can weigh; "he was arrogant and territorial" is a diagnosis, and the only thing it evidences is how you will describe your future colleagues. The second requirement is that you tried something and that the attempt is in the answer: what you said to them directly, what changed, what did not. The third, most often missing, is a sentence acknowledging their position — that he had been burned by a bad merge, that his standards were higher than the team's and not wrong. Interviewers are listening for whether the difficulty was mutual and whether you can see that, because everybody has worked with somebody difficult and only some people become the story.

That it contains a decision of yours, a cost that landed on other people, and a change narrow enough to be checked. The decision is what makes it your failure rather than something that happened near you. The cost is what makes it a failure rather than a near miss, and it should be stated in the currency the consequence actually had — a slipped date, an outage, a resignation, money, a customer. The change is what the question is ultimately for, and it has to be specific: a check now run, a question now asked, a threshold now watched. Credibility also depends on tone. Delivered calmly, with what you knew at the time and why the decision was defensible then, it reads as judgement. Delivered apologetically it reads as a performance, and delivered defensively it does not read as a failure at all.

The omitted part is always the same: the moment you saw the signal and did not act on it.

Q: "Tell me about a significant failure."

SITUATION AND MY DECISION
  "I led the payments migration in Q1 2025 - moving from a
   deprecated provider, with a hard date because the old one was
   being switched off in March. I scoped it and I set the plan."

WHAT I GOT WRONG, AS A DECISION
  "I planned test coverage for the happy path and the obvious
   failures, and I explicitly decided to skip the refund and
   partial-capture flows because they were 3% of volume. I wrote
   that decision down. It was a deliberate trade, not an oversight."

THE PART CANDIDATES LEAVE OUT
  "Six weeks in, one of our engineers said in standup that refunds
   looked 'weird' in the sandbox. I said we'd look at it after
   cutover, and I did not write it down. That's the actual failure.
   The scoping call was defensible with what I knew; ignoring the
   one piece of evidence that contradicted it was not."

WHAT IT COST - specific, in the currency it landed in
  "We cut over on 3 March. Refunds against pre-migration
   transactions failed silently - 214 customers over nine days,
   about £31,000 not returned, found by support tickets rather
   than by us. Two of those customers went to their bank. We spent
   three weeks on remediation, the finance team reconciled it by
   hand, and the next feature slipped a month."

WHAT I DID IN THE MOMENT
  "Stopped feature work, wrote the manual reconciliation, and told
   the support and finance leads before I told my own manager,
   because they were the ones with customers on the phone."

WHAT I CHANGED - two things, both checkable
  "One: anything explicitly descoped goes on the cutover checklist
   as a thing to verify in production, not as a thing we decided
   not to test. Two: 'that looks weird' from anyone on the team is
   now a ticket the same day. It costs nothing and it's the signal
   I threw away.
   I'd still descope refunds under that deadline. I wouldn't
   ignore the standup comment."

The answer works because the cost is countable and lands on identifiable people: 214 customers, thirty-one thousand pounds, nine days undetected, three weeks of somebody else's manual work. Those are consequences an interviewer can weigh, and they are the reason this reads as a failure rather than as a story about a tight deadline.

The section labelled as omitted is the one that separates a strong answer from a competent one. Most candidates offer the scoping decision as the failure, which is generous to themselves in a way that is visible from outside — a defensible trade-off is not a failure. The failure is the standup comment, and naming it shows that you have distinguished the two yourself.

Telling support and finance before your own manager is a detail worth keeping. It answers, without claiming anything, the question of whose problem you thought it was.

The final sentence does the most work in the whole answer. Separating the decision you would repeat from the specific signal you missed is what makes the contrition proportionate, and it produces a lesson narrow enough to have actually changed behaviour. "I would do everything differently" is not a lesson, it is a mood.

Whether the cost landed on somebody other than you. A missed personal deadline you absorbed by working a weekend, a design you abandoned before it shipped, a technology you evaluated and rejected — these are inconveniences, and offering one as a failure tells the interviewer you either do not have a real example or will not tell it. A failure has a consequence somebody else experienced: a customer, a colleague, a finance team, a date the business had told someone about. The test to run on your own story is whether you can name who paid. If the answer is nobody, or only you, find another story. The second-order tell is scale: a failure with a cost too small to matter is usually a boast about standards wearing a failure's clothes.

Chronologically, with the blast radius stated first, and without narrating the incident as an adventure. The shape that works is: what you changed, what broke and for whom and for how long, how it was detected — and be honest if a customer detected it — what you did in the first ten minutes, and then the systemic finding rather than the human one. That last part is what the question is for. An outage caused by a person is almost always an outage a system permitted, so the strong answer names the missing guardrail: no staged rollout, an alert that did not exist, a migration with no dry run, a config path with no review. Say what changed in the system afterwards, and if nothing did, say that too, because an outage with no remediation is a real and revealing fact about the organisation you were in.

By describing the mechanism rather than the person, and by keeping your own decision in frame. "The requirements changed three times in five weeks, and my mistake was not putting a change-control conversation in place after the second time" attributes the cause accurately and still contains you. Compare "the product manager kept changing his mind", which is the same fact with the candidate removed, and which an interviewer hears as a person who will describe this team that way in eighteen months. Two rules make it safe. Name roles rather than people, and never say anything you would not say with them present. Where another party genuinely was the cause, the sentence that lets you say so is the one about what you could have done about it — because the interesting question is never whose fault it was, it is what you did once you knew.

One of three things, all of them bad, and they will pick whichever fits the rest of the interview. That you have not done work with enough consequence to fail at, which puts a ceiling on the level. That you cannot recognise your own mistakes, which predicts an engineer who is hard to give feedback to and who repeats things. Or that you have one and will not tell it, which reads as managing the interviewer rather than answering, and is the reading that costs most at senior levels because judgement cannot be assessed on curated evidence. "I can't think of anything major" is scored as a non-answer, not as an absence of failures. The floor of preparation is one real failure you can tell calmly, with a cost, and this is the single most predictable question in the round.

With feedback that was actually critical, that you initially disagreed with, and that changed something. The commonest weak version is disguised praise — you were told you take on too much, you care too deeply — which the interviewer has heard forty times and scores as evasion. The strong version has three parts: the feedback in the words it was given in, your honest first reaction including the part where you thought it was unfair, and what you tested or changed as a result. Saying that you disagreed at first is not a liability, it is the thing that makes the rest believable, because nobody accepts hard feedback gracefully in the moment. What to avoid is feedback you have clearly not accepted, since a story that ends with you having been right is an answer to a different question.

Getting a decision changed or a piece of work adopted when you cannot instruct anybody, which is the ordinary condition of every senior engineer. In practice it is four things. Understanding what the decision's owner is measured on, because an argument that does not touch their incentives will not move them however correct it is. Finding evidence cheap enough that nobody has to concede on authority. Writing it down, because a document can be circulated, amended and adopted by somebody else while a conversation cannot. And making the smallest reversible version of the change available, so agreeing costs less than resisting. The reason interviewers ask about this rather than about leadership is that it cannot be faked by position: it shows whether you can produce a change in an organisation that has not given you any levers.

Influence answers score on the order of operations, which is why the sequence is worth having explicit.

flowchart TD
    A[Name the decision and who owns it] --> B[Find what the owner is measured on]
    B --> C[Talk to the loudest sceptic privately]
    C --> D[Write one page: options with costs]
    D --> E{Owner engages with the page}
    E -->|yes| F[Smallest reversible trial<br/>with a date and one metric]
    E -->|no| G[Escalate the decision<br/>never the grievance]
    F --> H[Owner presents it as theirs]

The first box is the one candidates skip, and skipping it is why so many influence stories are really stories about being ignored. If you cannot name who owns the decision, you are broadcasting an opinion, and the answer will have no mechanism in it — just persistence and eventual mysterious agreement.

Talking to the sceptic privately before the group discussion is the highest value move on the diagram. In a meeting a sceptic has an audience and a position to defend; alone, they will usually tell you the real objection, which is frequently not the stated one and is frequently something you can accommodate. Arriving at the meeting with their objection already addressed converts your opponent into a source.

The document matters for an unromantic reason: it is the only artefact that works while you are not in the room. Options with costs, rather than a recommendation, also gives the owner something to decide instead of something to accept, which is the difference between influence and a request.

The reversible trial is how you get past risk aversion rather than past disagreement. Most people who block a change are not disputing the idea, they are declining the downside, and a two-week trial with a stated metric and a date to stop moves the question from whether you are right to whether the experiment is cheap.

The last box is deliberately unglamorous and is what interviewers listen for at senior level. If the decision owner presents the change as their own, it will stick; if you need the credit, you will win the argument and lose the adoption.

By supplying the thing the owner is short of, which is almost never opinion. Most often it is evidence — a number, a log, a month of usage data — or a written comparison of options they have not had time to assemble, or the reduction of their risk to something small and reversible. The sequence matters as much as the substance: understand the constraint they are actually under, address the strongest objection before the meeting rather than in it, and give them a version of the decision that is theirs to make. The answer fails when it is a story about persistence, because repetition is not influence and interviewers hear it as somebody who wore a team down. It also fails when it ends with you being proved right later, which is an outcome rather than a method.

Find out what the scepticism is made of first, because there are only a few kinds and they need different responses. Scepticism about the risk is answered with a reversible trial and a rollback plan. Scepticism about the cost is answered with options at different prices, including a cheap one you do not prefer. Scepticism about you is answered by somebody else, which is why recruiting one credible ally before the conversation does more than any argument you could make. Scepticism born of a previous failure — they tried this in 2022 and it went badly — is answered only by acknowledging it explicitly and saying what is different, and it is the one candidates never see coming. What does not work is volume, or a business case that lists benefits without naming what it displaces.

Commit, and then make the risk observable rather than carrying it privately. Practically that means writing down what you expect to go wrong and what the early indicator would be, agreeing with the decision owner what would cause a revisit, and instrumenting the thing so the evidence arrives before the damage does. Then you execute the decision properly, because a half-hearted implementation of a plan you disliked produces exactly the failure you predicted and nobody will believe it was the plan. If the indicator fires, you bring it as new information with a recommendation attached, not as a reopened argument. The version of this answer that fails is the one where the candidate was right and says so, because interviewers are hiring for what you did with the risk, not for the pleasure of the vindication.

In private, about a specific occasion, framed as the effect on the work rather than on your feelings, and with something you want instead. "In the last two planning sessions the priorities changed after we'd started, and it cost us about a week of half-finished work — could we hold the list for the sprint, or tell me which item is the one that might move?" is deliverable to almost any manager, because it is dated, costed and comes with an ask. What makes it possible at all is having asked for feedback yourself first, which establishes that the channel runs both ways. The strong version of this answer in an interview includes a case where it did not land, and what you did next — because upward feedback that is ignored is common, and how you handled that is more informative than a story where the manager thanked you.

By showing what changed their mind rather than what you said. A strong answer identifies the actual reason the person held their position, which is usually not the reason they gave, and then names the thing that moved it: a number, a prototype, a customer's words, a colleague they trusted, a trial small enough to say yes to. It also credits them, because a story where somebody was comprehensively wrong and then capitulated is either untrue or unflattering to you. The best version admits that the position you both ended at was not the one you started with, since genuine persuasion usually moves both parties. What scores badly is the answer where you simply explained it better the third time, which is a story about their slowness rather than your influence.

By treating it as a question about your conduct, which is what it is. Give the behaviour and its impact on the work, what you tried directly with them before involving anybody else, what actually changed, and what you would do sooner next time. The two things interviewers are listening for are whether you went to the person before going around them, and whether there is any acknowledgement that the friction had two sides. Include the part where your first attempt did not work, because it almost never does and its absence makes the story suspect. The answer that fails is not the one where the relationship stayed difficult — that is normal and can be said — it is the one that is a character assessment delivered to a stranger, which predicts precisely how you will discuss this team later.

Whether new information can move you, and whether you can identify what moved it. The strong answer names the position you held and why it was reasonable, the specific evidence that contradicted it, and what you did once you knew — because changing your mind privately is cheap and saying so publicly is not. Interviewers are also checking the trigger. A mind changed by evidence is a good signal; a mind changed by seniority or by fatigue is the opposite, and candidates occasionally tell the second story believing it is the first. What scores badly is a change of mind about something you had no stake in, which is not a change of mind, and any version where you were persuaded to the position you had privately preferred all along.

Directly, with the date, the size of the miss, and who found out when. The structure that works is: what the commitment was and who made it, when you first knew it was at risk, what you did with that knowledge, what you did about the scope, and what the miss cost. The part being assessed is almost entirely the timing of the communication — a slip reported six weeks out with options is normal delivery, and the same slip reported in the last week is the actual failure, because everyone downstream planned on a number you knew was wrong. Say which one yours was. If it was the second, that is the failure to own, and the change to describe is a re-baselining habit rather than a promise to estimate better.

By describing how you moved rather than how you waited. The behaviour interviewers want is a decision made explicitly under uncertainty: you wrote down the assumption, you named who would need to confirm it, you picked the option that was cheapest to reverse, and you set a date at which you would revisit. The answer that fails is the one where the resolution was somebody else deciding — "I escalated it and got clarity" — because that describes waiting with an extra step. Two details lift this answer. Say what you did to reduce the ambiguity cheaply, such as finding the three actual users or reading the one log that settled it. And say what you deliberately left undecided, since knowing which ambiguity does not need resolving yet is the more senior half of the skill.

The block is the triage as it was actually written, because the reasoning is what gets scored and it lives in the ordering.

Friday 14:00. Four things, one of me, a release at 17:00.

A  Production: checkout errors at 4%, rising since 13:20
B  The release itself: 6 changes, cutoff 16:00, marketing emailing
   customers on Monday
C  Security: a dependency CVE, mailed by the platform team at 11:00,
   "please patch this sprint"
D  A director asking for numbers for a board slide by Monday 09:00

WHAT I DID, IN ORDER, AND WHY

14:00  A first, alone, no discussion. Customer money is failing now
       and the error rate has a direction. Nothing else on this list
       is happening while that is true.
14:10  Told the release owner and the director, in one message each,
       before either asked: "checkout is erroring, I'm on it, release
       is at risk, I'll tell you by 15:30." Cheap, and it stops both
       of them planning on the old picture.
14:40  Cause found: a config change to the payment timeout at 13:15.
       Reverted. Errors back to 0.2% by 14:55.
15:00  B, with a decision: pulled two of the six changes rather than
       delay the release, because the marketing email was the fixed
       constraint and those two were not in it.
16:00  Release out with four changes.
16:15  D: sent the director the three numbers she actually needed
       and said the fourth needed a query I'd run Monday morning.
       Partial and on time beat complete and Monday.
16:30  C: read the CVE properly. Not remotely exploitable in our
       deployment, no public exploit. Ticketed for Monday with the
       reasoning written down, and told the platform team that.

WHAT I GOT WRONG
  I should have told the release owner at 13:25 when the graph
  turned, not at 14:10. She'd already started the release checklist.

The ordering is the answer. Live customer impact outranks everything, the fixed external commitment outranks the internal one, and the item with an authoritative-sounding requester but no real deadline goes last — after somebody has actually read it, which is the step that converted C from urgent to Monday.

The message at 14:10 is the part that distinguishes this from a story about working quickly. Telling both stakeholders before they asked cost two minutes and removed the two interruptions that would otherwise have arrived at 15:00, and it let them replan while replanning was still cheap.

Two of the six changes being pulled is the decision worth leading with in an interview. Protecting a date by reducing scope, against a named external constraint, is a trade-off; delaying everything or working until nine is not.

The last block is what makes the whole thing credible. A triage story with no error in it reads as reconstructed, and the specific admission — that the release owner should have been told forty-five minutes earlier — is both true to life and the same lesson as most incident reviews.

By reproducing the explanation, not by asserting that you are good at it. Interviewers ask this and receive "I'm good at translating technical concepts", which evidences nothing; what they want is the sentence you actually said to the finance director. Give the audience, what they needed the explanation for — a decision, a customer conversation, a budget — and then the framing you chose, usually a cost, a risk or an analogy in their own domain. The detail that scores is what you left out and why, since the skill is compression rather than simplification. It also helps to say how you found out it had landed: they asked a good question, they used your framing in the next meeting, they made the decision. If the first attempt failed and you changed the framing, that is the better story.

With a named person, a specific gap, and something you did that a passive colleague would not have done. The gap has to be concrete — they could build to a spec but froze when the requirements were vague, they wrote code faster than anybody and never wrote anything down — because a story about somebody who was already good and then got promoted has no causal role for you in it. What you did should have a cost attached: the work you handed over knowing it would take longer, the uncomfortable piece of feedback you gave, the review you stopped fixing for them. Then say what they can do now that they could not before, and be willing to name the part that did not work. Answers that retreat into process — we had weekly catch-ups — score as supervision rather than development.

Because the generic answers are interchangeable and therefore unusable: solving hard problems, learning, working with smart people. Every candidate says them, so they discriminate nothing and the interviewer records no signal. A specific answer names a kind of work and offers evidence that you have sought it out. "Systems where I can see the effect on somebody using it — the two projects I've chosen to move onto were both closer to the customer than the one before" is checkable against your CV and predicts whether this role will hold you, which is the actual purpose of the question. It is a fit assessment, not a values test. That means the honest answer is in your own interest: getting hired into work that does not motivate you is a bad outcome for you first.

The same true situation, said three ways. Only one of them is safe.

Situation: your team was reorganised, the interesting platform work
moved to another group, your manager left, and you have been doing
maintenance for eight months.

WORST - true, unfiltered, disqualifying
  "Honestly the reorg gutted the team. All the interesting work went
   to the platform group because their director is better at politics,
   my manager left and the replacement is a project manager who
   doesn't understand what we do. I've been doing bug fixes for eight
   months and nobody seems to care."

  Every fact may be accurate. What the interviewer hears is somebody
  who will describe them this way in a year, and who assigns causes
  to other people's politics. The reorg is now the least interesting
  thing about your answer.

BETTER BUT WEAK - safe and empty
  "I'm looking for a new challenge and an opportunity to grow."

  Says nothing, and the follow-up - what challenge, and what stopped
  you finding it there - has to be answered anyway, now from a
  standing start. It also reads as a concealment, which invites more
  probing than the honest version would have.

BEST - specific, forward-facing, no villain
  "The team was reorganised last year and the platform work I was
   hired for moved to another group. I asked to follow it and it
   wasn't possible, and I've spent the last eight months on
   maintenance, which I've done properly but isn't where I want to
   spend the next three years. So I'm looking for a role where the
   systems work is the job rather than the leftover - which is why
   I'm talking to you specifically about this one."

  Same facts, no attribution of motive, and one sentence of evidence
  that you tried to fix it internally first.

The test for any version
  Would you be comfortable if your current manager heard it?
  If not, it is the worst version wearing better clothes.

The structural difference between the worst and the best version is not honesty, it is the attribution. Both describe the same reorganisation; only one explains it by other people's character. Interviewers treat this as the most reliable predictor in the whole round of how you will talk about them, because it is the one moment where you are invited to criticise an employer and have to choose how.

The sentence about having asked to follow the work is doing specific work. It pre-empts the obvious follow-up — did you try to fix this — and it converts the answer from a complaint into a decision made after an attempt.

The empty version is worth understanding as a failure too, because candidates retreat to it believing it is safe. It costs you the chance to say what you want, which is the useful half of the question, and it usually produces four more questions rather than none.

The final test is the one to actually use under pressure. If you would not want the person you are leaving to hear the sentence, do not say it, because the interviewer is a stranger with no reason to take your side and every reason to generalise.

Culture fit, asked badly, measures similarity — would we enjoy a pint with this person — and reliably reproduces whatever the team already is, including its blind spots. The defensible version is much narrower: whether the way you work is compatible with how this team actually operates, which is a question about written-versus-verbal communication, tolerance for disagreement, autonomy, on-call expectations and pace. Culture add asks the more useful question of what this team does not currently have that you would bring, which is answerable with evidence rather than with vibes. For a candidate, the practical implication is to convert the question into the specific one: ask how decisions get made and how disagreement is handled here, then say honestly how you work. Discovering a mismatch in the interview is a good outcome, not a failed one.

With something you could not have said about their competitor, and with what you want from the role rather than only what you admire about the company. The shape that works is one specific thing about the product, the problem or the engineering that you have actually looked at — a public write-up, the way the API is designed, the scale of the data problem, a decision they published — connected to work you have chosen before. Then the honest second half: what you want the next two years to contain, and why this role looks like it. Flattery fails because it is unfalsifiable and because interviewers hear their own marketing copy repeated back all day. Saying "I don't know enough yet, here's what I've read and here's what I want to ask you about it" is stronger than a rehearsed compliment.

Questions are scored. These earn information and are not performative.

ASK                                    SIGNALS                     GETS YOU
-------------------------------------  --------------------------  -----------------
"What does the on-call rota look        You have operated           The truth about
 like, and what paged you last week?"   production systems and     sustainability.
                                        will ask before joining.   Hesitation is
                                                                   the answer.

"How was the last significant           You care how decisions      Whether decisions
 technical decision made - who          get made, not who is        are made or
 decided and how was it written         in charge.                 announced.
 down?"

"What's on the roadmap that the         You expect trade-offs       Their honesty,
 team disagrees about?"                 to exist and be aired.      and whether
                                                                   disagreement is
                                                                   safe here.

"What would you want me to have         You think in outcomes       A concrete brief,
 delivered by month three, and          rather than tasks.          or the discovery
 who would notice?"                                                that nobody has
                                                                   defined the role.

"Who left the team in the last          You do the diligence.       The thing no
 year, and why?"                        Slightly bold; ask it       glassdoor page
                                        of the manager, not         will tell you.
                                        the panel.

"What's the part of this codebase       You expect legacy and       Whether they are
 you'd warn me about?"                  are not precious.          candid, and what
                                                                   you are inheriting.

"What have you personally changed        Reciprocity - you asked    How the person you
 about how the team works?"              about their agency.        would work for
                                                                   actually operates.

DO NOT ASK
  Anything on the careers page. Signals you did not read it.
  "What's the culture like?" Unanswerable, gets you adjectives.
  "Do you have any concerns about me?" Invites a rehearsal of
    your weakest moment and rarely changes the outcome.
  Salary and holiday, at a technical round. Right question,
    wrong room - that conversation is with the recruiter.

The pattern across the good questions is that each one has a factual answer that can be uncomfortable. That is what makes them informative: a question the interviewer can answer with a slogan tells you nothing, and the hesitation before an honest answer about the rota or the last departure is usually more useful than the answer.

They also happen to signal seniority, which is why they are scored. Asking what paged somebody last week is only a natural question for a person who has been paged, and asking how a decision was written down is only natural for somebody who has needed the record later.

The last question in the list is the one to save for the hiring manager. It asks what agency they have actually exercised over the team, and a manager who cannot name anything has told you the answer to several other questions at once.

The prohibitions matter as much as the list. A question already answered on the careers page is scored as inattention, and "any concerns about me?" is a common piece of advice that mostly produces a closing minute spent on your weakest answer.

With something they actually said, including the critical part. The question is a self-awareness test wearing a reference's clothes, and the giveaway is an answer containing only strengths, because no real manager's assessment looks like that. The shape that works is two sentences of what they valued, quoted or close to it, then the thing they pushed you on and what you did about it — ideally the same development area you have named elsewhere in the interview, since consistency across answers is itself being checked. It also pays to be specific about which manager and when, because "my manager in 2024, in my last review" is checkable and "my managers have generally said" is not. Anything you would not want that person to be asked to confirm is the wrong answer.

Most of these are said by competent candidates who have never heard them read back.

YOU SAY                          THEY HEAR
-------------------------------  ----------------------------------------
"I would probably..."            You have no example. Recorded as no
                                 evidence, whatever follows.

"We decided to..."               I cannot tell what you did. If the whole
                                 answer is like this, nothing is scored.

"To be fair to them, but..."     A criticism with a disclaimer bolted on.
                                 The disclaimer is not heard.

"It was a learning experience."  The sentence that replaces the lesson.
                                 Say what changed or say nothing.

"There was a lot of politics."   You explain outcomes by other people's
                                 motives. Predicts how you will describe
                                 us.

"Management wouldn't listen."    You have never got a decision changed
                                 without authority.

"I'm a bit of a perfectionist."  You have not thought about the question,
                                 and you think this is a strength.

"I don't really have any         Either nothing consequential has been
 failures that come to mind."    yours, or you will not tell me. Both
                                 cap the level.

"That's a great question."       Filler. Harmless once, a tic by the
                                 fourth time, and it buys thinking time
                                 less well than a pause does.

"Honestly?"                      Prefaces the sentence you are about to
                                 regret. Almost always followed by the
                                 unfiltered version of a fact you had a
                                 safe version of.

"I just got on with it."         You absorbed a problem instead of
                                 surfacing it. Reads as heroism, scores
                                 as poor communication.

"I basically ran the project."   "Basically" is doing load-bearing work.
                                 Invites a probe into what you actually
                                 owned.

The through-line is that each phrase removes evidence. Conditional tense removes the event, "we" removes your decision, "learning experience" removes the lesson, and "politics" removes any mechanism you might have used. An interviewer with a scorecard and no quotable specifics writes down that they got nothing, and that is a rejection rather than a neutral.

The second cluster is about attribution. Every phrase that explains an outcome by somebody else's character or motives is heard as a prediction, because it is the only sample the interviewer has of how you discuss colleagues. This is the cheapest thing on the list to fix and the most expensive to get wrong.

"Honestly?" deserves its own note because it is a reliable signal that a candidate is about to abandon a prepared answer. If you notice yourself saying it, pause instead; the unfiltered version of a true fact about a former employer is the commonest self-inflicted rejection in the round.

Nothing here is about polish. A candidate who says "um", loses their thread and restarts scores perfectly well, because the evidence is still there. These phrases fail for the opposite reason: they are smooth, and empty.

Because rehearsal usually produces a narrative rather than a memory, and the two degrade differently. A narrative has a shape, a lesson and a satisfying ending, and it contains exactly the details the candidate decided to include — so the first question outside that set has no answer. A memory has irrelevant detail in it: what day it was, who was annoyed, the thing that was going on at the same time, the part that never got resolved. That texture is what interviewers use to distinguish the two, mostly without articulating it. The fix is not less preparation but a different kind: prepare the event rather than the telling. Recover the dates, the names, the numbers and the loose ends, then let the wording vary, because a story delivered identically twice is one of the tells.

You can choose which story to tell, which parts to lead with, and how to frame your own role generously — and you cannot change facts, borrow someone else's work, or invent a number. The line is not primarily ethical, it is practical: every fabricated element is a thing you have to remember consistently under three probes, in two rounds, sometimes against a reference. What is entirely legitimate is claiming your actual contribution clearly, which candidates under-do far more often than they over-do. If your part was one of four, say so and describe your part precisely; that scores better than an inflated claim because it lets the interviewer trust the details. The one thing to say when you are unsure is the truth about your uncertainty — "I think it was around six weeks, I'd have to check" — which costs nothing and protects everything else.

With a real weakness that has a cost you can name and a mitigation somebody could observe. The failures are well known and still ubiquitous: the humblebrag — perfectionism, caring too much, working too hard — which tells the interviewer you will not engage with the question, and the disqualifier, which is a weakness central to the job you are applying for. In between there is plenty of honest ground: you write documentation late and now block time for it before the work is done, you avoid interrupting people and have missed things as a result, you go deeper on interesting problems than the deadline warrants and now agree a timebox. The structure is the weakness, an occasion where it cost something, and the specific mechanism you use now. Do not claim it is fixed.

"Tell me about a time you were wrong, and how you found out." It resists preparation because it needs an event where the candidate held a position, something contradicted it, and they can describe both — much harder to manufacture than a failure story. A strong answer names the position and why it was reasonable at the time, identifies the evidence that broke it, is honest about the gap between that evidence arriving and being accepted, says who else was affected meanwhile, and describes a change to how they now test their own positions. It credits the person who was right, without deference. A weak answer substitutes one of three things: being wrong about something with no stake in it, being technically wrong and morally vindicated, or the discovery of the error framed as their own initiative when it plainly came from somebody else. The underlying test is whether being wrong is something the candidate can hold calmly and describe accurately, because an engineer who cannot do it here cannot do it in a design review or an incident either.