Software engineer behavioural interview questions

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.

Answer this one — free, no sign-in →

The question

Describe a production incident you were responsible for.

What this is testing: To follow your reasoning in real time: what you saw, what you suspected, what you ruled out and in what order.

Your answer

0 words · stays in this tab · ⌘/Ctrl+Enter

“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.

Answer this one — free, no sign-in →

The question

Tell me about a technical approach you argued for that others resisted.

What this is testing: To see whether you can hold a position on the merits, and whether you can tell the difference between being overruled and being wrong.

Your answer

0 words · stays in this tab · ⌘/Ctrl+Enter

“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.

Answer this one — free, no sign-in →

The question

Describe a project where you underestimated the scope.

What this is testing: Estimation is a proxy for how you handle being wrong in public, repeatedly, in front of people who are planning around you.

Your answer

0 words · stays in this tab · ⌘/Ctrl+Enter

“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.

Answer this one — free, no sign-in →

The question

Tell me about a time you had to get productive in an unfamiliar codebase.

What this is testing: This is the question that predicts the first three months of the job more than any other.

Your answer

0 words · stays in this tab · ⌘/Ctrl+Enter

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.

Build my interview