Behavioural interview questions for senior engineers, with real answers

Seven questions that expose judgement, each with a weak answer and a strong one, plus the failure question that defeats even the prepared.

Caption: The empty chair most candidates walk into cold, having spent every prep hour on algorithms that nobody in the loop is going to ask about.

The round that quietly does the rejecting

Your coding round is not what is killing you. I sat in the debrief rooms, and the sentence that sank senior candidates was almost never "the code was wrong". It was "I could not tell what they actually decided."

At junior level, behavioural questions test whether you are pleasant to work with. At senior level, they test whether your judgement can be trusted without supervision. Different bar, same forty-five minutes, and nobody tells you the bar moved.

What the interviewer is actually writing down

There are four columns on the scorecard, whatever the company calls them.

Scope: how big was the thing you actually owned, versus the thing you were standing next to. Influence: did you move engineers who did not report to you. Conflict: what happens when someone senior disagrees with you and you are still right. Ownership: can you describe being wrong without smuggling in an excuse.

Everything else is small talk. If your story does not put evidence in one of those four columns, you spent your minutes on nothing.

The naive advice: STAR is a container, not an answer

You already know STAR. Situation, task, action, result. Every guide stops there, which is exactly why STAR-shaped answers all sound identical and all fail.

STAR tells you the order to speak in. It does not tell you what has to be inside. Five pieces, no more: the situation in one sentence, the decision you made, the path you rejected, what it cost, and the result or an honest admission that you do not have a number.

Most people spend three minutes on the first piece and skip the middle two entirely. Those middle two are the whole gap between a mid-level answer and a senior one, and they take about two sentences.

"We could have blue-greened it, but we only had one spare node. So it was six hours of read-only mode on a Saturday."

Say that in an interview and you will see the interviewer's pen stop.

Caption: Both answers follow STAR faithfully. The senior one spends its minutes on the alternative that was rejected and the cost that was paid, the two fields the scorecard is actually waiting for.

Seven questions, weak answer against strong

"Tell me about a technical decision you disagreed with." Weak: "I raised my concerns and then supported the team's direction." Strong: "I thought the event bus was overkill for four services. I wrote up the failure modes, got outvoted, and built it. Six months later two of my three predicted failures happened. I did not say I told you so, I used the write-up as the starting point for the rollback plan." The written record is what turned a disagreement into evidence.

"How did you influence a team you did not manage?" Weak: "I set up a meeting and explained the benefits." Strong: "I stopped arguing and shipped the migration for one low-traffic service myself, then showed them the p99 dropping 40%. Two teams copied it in a fortnight. The third never did, and I let it go." The demo made the case better than any slide could, and admitting one team refused is what stops it sounding like a fairy tale.

"Describe a time you had to push back on a deadline." Weak: "I explained that quality would suffer if we rushed." Strong: "I said we could ship the whole thing in six weeks or the payment path alone in three. I recommended three, because the other half had no users waiting on it. We shipped in three and the rest never got built, which told me my scoping was right." He turned a refusal into a negotiation by putting a smaller, concrete option on the table.

"Tell me about mentoring someone." Weak: "I did regular one-to-ones and shared my knowledge." Strong: "I stopped answering her questions and started asking what she had already ruled out. Painful for a month. By the end of the quarter she was reviewing my pull requests and caught a race condition I had missed." The mentee ended up sharper than the mentor in a specific area, and he was secure enough to say so.

Each strong answer comes down to a choice and a consequence. The next three work the same way, so I will be quick.

"How do you handle competing priorities across stakeholders?" Weak: "I prioritise based on business impact." Strong: "I put both requests in one document with the engineering cost next to each, sent it to both directors, and told them I would build whichever they agreed on by Friday. They agreed by Wednesday." He forced the real decision-makers to decide, without escalating anything as a complaint.

"Tell me about a project that did not go well." Weak: "The requirements kept changing." Strong: "I underestimated the data migration by a factor of three because I tested on a sanitised dump. Four teams were blocked for a week. I now refuse to estimate any migration without touching production-shaped data." The interviewer hears someone owning the mistake, not explaining it away.

"When did you decide not to fix something?" Weak: "We logged it as tech debt for later." Strong: "The retry logic was ugly and I left it ugly for eight months. It was in a batch job that ran nightly with a human watching it. I fixed the connection pool instead, because that one was in the request path." Of the seven, that is the one that separates people, because leaving something broken for a solid reason says more about your judgement than any success story will.

The failure question is where the room goes quiet

Of those seven, the failure question earns its own section, because it is the one that takes senior candidates apart without anyone raising their voice.

It is never because the failure was too big. The problem is the pivot. Somewhere around sentence four, the candidate starts moving the blame outward. The vendor was unreliable. The spec was vague. Leadership changed direction. Every clause is probably true, and every clause moves the failure one step further from the person speaking.

I did this myself, at a company I badly wanted to work at. I described a cache invalidation bug that caused a 12-hour outage, then spent the rest of the answer blaming the library's undocumented behaviour. Accurate. It still got me rejected.

An honest failure answer has exactly one villain, and you have to be it.

The version that works is short. Name the decision. Say why it made sense with the facts you had. State the cost plainly, in hours or money or somebody's weekend. Then finish with the change you actually made, and a time you have already used it since. That last part is what nobody prepares, and it is what turns a confession into evidence.

Prepare four stories, not twenty answers

Stop building an answer per question. You will never have enough, and the joins will show the moment you get asked something off-script.

Build four stories instead, each aimed at a different column. A story where you were technically right and got overruled anyway, which covers disagreement, influence and conflict. A story where you were plainly wrong and it cost real money, which covers failure and ownership. Something you shipped across a boundary you did not control, for scope and stakeholders. And one where you picked the dull, safe option on purpose and defended it, for judgement and tech debt.

Write each at three lengths: thirty seconds, two minutes, and five minutes with the architecture drawn out. Then, for each, write the two sentences that are always missing. What you rejected. What it cost. Rehearse those two specifically, because under pressure they are the first things to fall out.

Four stories, twelve versions, two hard sentences each. An evening of work, and it covers every behavioural question a senior loop will throw at you.

What it cost me to learn this

I have been on both sides of this and lost on both.

As a candidate, that sanitised failure answer cost me a job I wanted. As an interviewer, I once pushed hard for a candidate who told stories beautifully, and I ignored that not one contained a decision he had personally owned. He was with us a bit over a year. Every design doc he wrote was a summary of what other people thought. My read, my push, my mistake, and the team paid for it in wasted design-review hours long after I had stopped feeling clever about the hire.

The cost of getting this wrong is not one bad interview. It is a year of being the person nobody escalates to.

The warning

Do not over-correct into the confident-jerk answer. There is a version of this advice that turns into blaming your old team with better grammar, and it reads worse than vagueness.

Match the scope you claim to the blast radius you can describe. If you say you led a migration, be ready for what broke in week three, who was paged and what you rolled back. Claim the small thing you owned completely over the big thing you were adjacent to, every time. Interviewers do not verify job titles. They verify whether the details hold when pushed.

And if you genuinely do not have a story with a decision and a cost in it, do not manufacture one. Go and get one at work first. A modest answer that survives follow-up questions beats an impressive one that collapses on the second probe.

Tonight, pick your four stories and write the two missing sentences for each. That is the whole preparation. Now, which of the four columns, scope, influence, conflict or ownership, do you have the weakest story for right now?