The behavioural round is where engineering offers are usually lost, and it is the half most people do not rehearse. The questions look soft. They are not: they are looking for whether you can be trusted with a decision when nobody is watching, and whether you can explain a technical choice to someone who will not be impressed by the details.
What this round is actually assessing
Judgement under production pressure
Not whether you fixed it — whether you can say what you knew at each step, and why you tried that next.
Explaining a technical decision to a non-engineer
Interviewers listen for whether you can drop a level of detail without becoming vague. Most candidates do one or the other.
Disagreement without escalation
A code-review story reveals more about seniority than any system-design question, because there is no right answer to hide behind.
What you own when it goes wrong
The strongest version of this is specific and unsentimental. It is also the rarest.
The questions, and what each one is for
“Describe a production incident you were responsible for.”
Why they ask it
To follow your reasoning in real time: what you saw, what you suspected, what you ruled out and in what order.
What a strong answer contains
The first signal, the wrong hypothesis you held for a while, what changed your mind, and what you changed afterwards so it could not recur that way.
The follow-up a vague answer earns
“What did you believe was wrong for the first ten minutes, and why?”
The mistake it catches
Jumping straight to the root cause. The diagnosis is the answer; the fix is a footnote.
“Tell me about a technical approach you argued for that others resisted.”
Why they ask it
To see whether you can hold a position on the merits, and whether you can tell the difference between being overruled and being wrong.
What a strong answer contains
The strongest version of their objection, stated fairly, and what actually settled it.
The follow-up a vague answer earns
“What was the best argument against you?”
The mistake it catches
Describing the other side so weakly that the story stops being about persuasion.
“Describe a project where you underestimated the scope.”
Why they ask it
Estimation is a proxy for how you handle being wrong in public, repeatedly, in front of people who are planning around you.
What a strong answer contains
When you knew, who you told, how quickly, and what you changed about the plan rather than about the hours.
The follow-up a vague answer earns
“How long between knowing and saying?”
The mistake it catches
Blaming requirements. Sometimes true, always unhelpful — the question is what you did next.
“Tell me about a time you had to get productive in an unfamiliar codebase.”
Why they ask it
This is the question that predicts the first three months of the job more than any other.
What a strong answer contains
A method: what you read first, what you changed first, and how you checked your understanding cheaply.
The follow-up a vague answer earns
“What was the first thing you shipped, and how did you pick it?”
The mistake it catches
"I just read the code." Everyone reads the code. The order is the answer.
A made-up answer, made specific
“Tell me about a time you debugged something difficult.”
The vague version
We had an issue in production where requests were timing out. I dug into the logs, found the problem, and fixed it. After that it was fine.
What is missing
There is no reasoning in it. Any engineer could have said this sentence about any incident, which means it distinguishes you from nobody.
The stronger version
Checkout latency went from 200ms to eight seconds, but only for about one request in twenty. I assumed the database, because the slow queries lined up, and I spent the first half hour there and found nothing. What changed my mind was that the slow requests all came from one region. It was a connection pool sized per instance while the load balancer was not distributing evenly, so two instances were saturated and the rest were idle. I resized the pool that evening and moved the pool config out of the image the following week, because the real problem was that it could differ per deploy.
Written as an illustration. It is not a customer, a transcript, or a result we measured.
Three questions worth asking them
“What is the part of this codebase that everybody warns new joiners about?”
“How does a disagreement between two senior engineers get settled here?”
“What does on-call actually look like in a normal week?”
Practise these against your own résumé
Add your résumé and the job description and the questions change: they ask about your work, by name, and the feedback quotes what you actually said.