Behavioural Questions

Behavioural rounds are not a formality. They are scored, they are where senior candidates are most often downgraded, and the difference is structure rather than the quality of your experience.

What is actually being tested

Every one is really asking: what will you be like to work with when something goes wrong?

The structure

Situation   where, when, what constrained you              15-20 seconds
Task        what YOU owned, and what success looked like   10-15 seconds
Action      the concrete steps — 3 or 4, not 12            45-60 seconds
Result      the measurable outcome, and the learning       20-30 seconds

Note the proportions. Most weak answers invert them — ninety seconds of context and ten seconds of what they did.

The question

“Tell me about a time a project you were responsible for did not go well.”

The answer that gets marked down

"So we had this data pipeline that had been around for a while, built before I
joined, and honestly the code was pretty bad — no tests, hard-coded paths, that
kind of thing. The team was under a lot of pressure because there was a big
product launch coming and management kept changing the requirements.

We were supposed to migrate it to the new platform. It was a mess really. There
were a lot of dependencies nobody had documented and the person who wrote it had
left. We tried our best but we ended up missing the deadline. I think if we'd had
more time and clearer requirements it would have gone better.

Eventually we got it done a few weeks late and it works fine now."

Nothing there is a lie, and it scores badly. Read what the interviewer heard:

The question was “a project you were responsible for”, and the answer never says what the candidate personally did or decided.

The same story, told well

SITUATION
"Last year I owned the migration of our order-ingestion pipeline onto the new
platform. Hard deadline: the old system's contract ended in eight weeks, and the
pipeline fed the revenue reporting the finance team closed the month on."

TASK
"I was the only engineer on it. Success was cut-over with no gap in reporting and
no manual reconciliation for finance."

ACTION
"I made three decisions, and the second one was wrong.

First, I mapped the dependencies by instrumenting the old system rather than
reading the code — the code was undocumented and the author had left. That found
four consumers nobody knew about, including a finance spreadsheet.

Second — and this is the mistake — I decided to migrate and refactor at the same
time. The old code was poor and I thought doing it once would be cheaper. That
turned a well-understood migration into a rewrite, and I could no longer diff the
new output against the old to prove correctness.

Third, when I was four weeks in and clearly behind, I stopped and re-planned. I
reverted the refactor, did a lift-and-shift so the outputs were byte-identical,
and scheduled the cleanup separately."

RESULT
"We cut over eleven days late. Finance closed the month on time because I'd kept
the old system running in parallel as a fallback — that was the one decision that
saved it.

The lesson I actually took was about coupling two changes. Migrating and
refactoring together removed my ability to verify correctness by comparison, which
was the only cheap verification I had. I now separate a move from a change as a
rule, and I've since applied it twice — most recently on the warehouse migration,
where we lifted-and-shifted first and cleaned up in the quarter after."

Same events, same eleven days late. What changed:

• “I owned”, “I decided”, “the second one was wrong” — ownership, including of the error.
• A specific, named mistake with a reason it seemed sensible at the time. This is what the question is for.
• Concrete constraints — eight weeks, contract ending, finance month-end.
• Recovery — noticing at four weeks and re-planning is the most valuable part.
• A transferable lesson, applied since. “I’d be more careful” is not a lesson; “separate a move from a change” is a rule, and naming a later application proves it stuck.

The interviewer’s scorecard

Ownership          strong   — "I decided", named own mistake without prompting
Self-awareness     strong   — identified the real root cause, not the circumstances
Judgement          strong   — re-planned at 4 weeks rather than pushing on
Risk management    strong   — parallel run protected the month-end close
Communication      strong   — one story, clear structure, ~2 minutes
Learning           strong   — stated as a rule, with a later application

Concern            none. Would work with.

Against the first version:

Ownership          weak     — no first-person decisions
Self-awareness     weak     — every cause external
Learning           none     — "more time would have helped"

Concern            may not take responsibility when things go wrong.

That last line is what a downgrade actually looks like. It is rarely “not technical enough”.

Prepare the follow-ups

Every good story invites three or four, and they are where rehearsed answers fall apart:

Q: "Why did you think refactoring at the same time was a good idea?"
A: "The code had no tests and hard-coded paths, and I expected to be the person
    maintaining it. Doing it once looked cheaper than twice. What I underweighted
    was that the migration had a hard deadline and the refactor did not — so I let
    a discretionary change inherit a non-negotiable date."

Q: "Who did you tell, and when?"
A: "I flagged the risk at the week-four checkpoint with a revised plan, not just
    the problem. My manager's first question was whether finance was protected,
    which is why the parallel run mattered."

Q: "What would you do differently now?"
A: "Set an explicit checkpoint at 25% of the timeline with a defined 'am I on
    track' test. I caught it at four weeks because it became obvious, not because
    I had planned to check."

Q: "Was eleven days late acceptable?"
A: "To the business, yes — the contract had a grace period and finance was never
    at risk. To me, no, because it was self-inflicted."

Preparing follow-ups is what separates a story you have lived from one you have memorised.

Build a story bank

Five or six stories cover almost every question, because each maps to several:

STORY                              covers
1. failed migration                failure, ownership, recovery, learning
2. disagreed with a senior eng     conflict, influence, being wrong
3. shipped under a hard deadline   prioritisation, tradeoffs, saying no
4. mentored a struggling colleague leadership, empathy, patience
5. found a bug in production       ownership, debugging, communication
6. proposed something rejected     influence, resilience, reading a room

Write each one as four bullets — not a script. A memorised script sounds memorised, and it breaks the moment the question is phrased differently.

FAILED MIGRATION
S: order pipeline, 8-week hard deadline, contract ending, feeds finance close
T: sole engineer, cut over with no reporting gap
A: instrumented to find deps (found 4 unknown) / coupled refactor to migration ← mistake
   / re-planned at week 4, lift-and-shift, parallel run
R: 11 days late, month-end protected. Rule: separate a move from a change. Applied
   on the warehouse migration.

Four lines. You can tell it in ninety seconds or expand any branch for five minutes.

Numbers make it credible

weak                              →  strong
"it was a lot faster"             →  "p99 went from 4.2s to 380ms"
"a big pipeline"                  →  "40 GB/day, 200 downstream tables"
"a lot of people used it"         →  "three teams, about 60 daily users"
"we saved a lot of money"         →  "cut the monthly bill from $12k to $4k"
"it took a while"                 →  "eight weeks, of which three were the mistake"

Approximate numbers are fine and are not challenged. Having none reads as not having measured anything — which, in an engineering interview, is the concerning interpretation.

Common failures

The “we” one is worth checking deliberately. Record yourself and count — most people are surprised.

Questions where the trap is different

“What is your greatest weakness?” — a real one, with what you do about it. “I go deep on problems past the point of usefulness. I now timebox investigations and write down what I would need to see to stop.” Not “I care too much”.

“Why are you leaving?” — forward-looking, never negative about the current employer, even if deserved. Criticising a current team is read as what you will say about this one.

“Tell me about yourself” — ninety seconds: where you are now, one or two things you have built, why this role. Not a chronological CV.

Practice

first attempt:  14 × "we",  2 × "I"
after rewrite:   3 × "we",  9 × "I"

felt like: 90 seconds
actual:    4 minutes 20 seconds

"a big pipeline"  →  "40 GB/day, 200 downstream tables"

"Why did that seem like a good idea at the time?"
"Who did you tell, and when?"
"What would you do differently?"

Next: the problem-solving framework — how to work a problem out loud.