Quick Answer
The 30 most common behavioural interview questions for software engineers cover conflict, failure, leadership, pressure, and initiative. Each one expects a structured answer — situation, task, action, result — delivered in natural, confident English. This article gives you the full question list, a model answer for each, and a graded ladder showing what junior, mid, and senior answers actually sound like, so you can calibrate your own.
What behavioural interviews actually test
Behavioural interviews test how you think and communicate under pressure — not just what you did. Every question asks you to reconstruct a past situation in real time, in a second language, while an interviewer evaluates whether you take ownership, whether you show judgment, and whether you can tell a coherent story. The technical content of your answer matters less than most engineers expect.
What is a behavioural interview question?
A behavioural interview question asks you to describe a specific past situation — 'Tell me about a time when...' — because interviewers assume past behaviour predicts future behaviour.
US and UK interviewers generally use behavioural questions to assess five things: how you handle conflict, how you respond to failure, how you take ownership, how you prioritise under pressure, and how you work with people who are not engineers. Your answer needs to address whichever of these five the question is probing — not just tell a technically impressive story.
The five dimensions interviewers are scoring
- Ownership — do you take responsibility, or do you describe what the team did?
- Judgment — did you make a considered decision, or did you react?
- Communication — can you explain a complex situation clearly and concisely?
- Growth — what did you learn, and did it change your behaviour?
- Impact — what was the measurable outcome, not just the activity?
Watch Out
The most common mistake non-native engineers make is answering in the passive voice: 'The bug was fixed' instead of 'I fixed the bug.' Passive voice hides your agency. Interviewers hear it as a lack of ownership, not a grammar choice.
The STAR framework — and where most engineers lose points
STAR — Situation, Task, Action, Result — is the standard structure for behavioural answers, and most engineers know it. The part most engineers get wrong is the ratio: they spend 60% of their answer on Situation and Task (the context), and rush through Action and Result (the part the interviewer actually cares about).
| Part | What it covers | Target length | Common mistake |
|---|---|---|---|
| Situation | The context — project, team, constraint | 2–3 sentences | Too long — interviewer already understands tech context |
| Task | Your specific responsibility in that situation | 1–2 sentences | Vague — 'I had to help the team' tells them nothing |
| Action | Exactly what YOU did, step by step | 4–6 sentences | Using 'we' throughout — hides your individual contribution |
| Result | The measurable outcome, plus what you learned | 2–3 sentences | No number, no learning — ends with 'it went well' |
Spend at least half your answer on Action and Result — that is where the interviewer's scoring happens.
Interview tip
Start your Result with a number whenever possible. 'The deployment time dropped by 50%' is more credible than 'it became much faster.' If you don't have an exact figure, give a relative one: 'roughly twice as fast' or 'we went from three days to same-day.'
Key takeaway
The non-obvious rule: your Action section should use 'I', not 'we' — even when the work was collaborative. Say what you specifically did, then credit the team: 'I proposed the approach and led the implementation; the team executed it together.'
"Tell me about yourself" — the question that sets the tone
'Tell me about yourself' is not a biographical question. It is an invitation to position yourself for this specific role. Most engineers answer it chronologically — starting from their degree and working forward — which wastes the first 90 seconds of the interview on information the interviewer already has from your CV.
Insight
A strong self-introduction runs 90 seconds to two minutes, moves from present to past to future, and ends by connecting your background directly to the role you are interviewing for.
The Present → Past → Future structure
- PRESENT: 'I am a full-stack engineer with five years of experience, currently focused on [specific domain].' — one sentence, your professional identity now.
- PAST: 'My background is in [key area]. In my most recent role at [Company], I [specific achievement] — for example, led the backend rebuild of a logistics platform that reduced API response time by 40%.' — two to three sentences, your most relevant proof point.
- FUTURE: 'I am looking for a role where I can [specific goal that matches this job] — which is why this position caught my attention.' — one sentence, closes the loop.
Notice what is not in that structure: your degree (unless it is directly relevant), your hobbies, or a list of every technology you have ever touched. Those details belong in answers to specific follow-up questions. The self-introduction is a positioning statement, not a CV reading.
Weak version (common pattern)
'I graduated in Computer Science in 2018 and started as a junior developer. I worked at several companies and used many technologies including Java, Python, and JavaScript. I enjoy learning new things and I am a team player. I am excited about this opportunity.'
Strong version (present → past → future)
'I am a full-stack engineer specialising in distributed systems, with five years of experience building backend services at scale. In my last role I led a team that migrated a monolithic logistics platform to microservices — that cut deployment time from three days to under two hours. I am now looking for a senior role where I can own architecture decisions end-to-end, which is exactly what drew me to this position.'
Interview tip
Practise your self-introduction until you can deliver it without hesitation. It is the one answer you can fully prepare in advance — and a fluent opening sets the tone for everything that follows.
Conflict and disagreement questions (with answers)
Conflict questions test whether you can disagree professionally — presenting evidence rather than opinion, and preserving the working relationship regardless of the outcome. Interviewers are not looking for someone who avoids conflict; they are looking for someone who resolves it constructively.
The 7 conflict and disagreement questions
- Tell me about a time you had a disagreement with your manager.
- Describe a time when you had a conflict with a teammate.
- Tell me about a time you disagreed with a colleague. How did you handle it?
- Describe a time there was a conflict within your team. How did you help resolve it?
- Tell me about a time you pushed back on a decision. What happened?
- Describe a situation where you had to deal with a difficult customer or stakeholder.
- Tell me about a time a colleague's approach was wrong. What did you do?
For Question 1 — disagreement with a manager — the structure that works best is: name the disagreement clearly, show the evidence you gathered before raising it, describe the conversation you had (not just the outcome), and then state what was decided and what you learned. The interviewer wants to see that you can challenge upward without being combative.
Model answer — disagreement with manager (Q1)
- SITUATION: 'In my previous role, my manager wanted to implement a new feature using a technology stack I believed would create long-term maintenance problems for the team.'
- TASK: 'My responsibility was to raise my concern clearly without undermining the decision-making process or the relationship.'
- ACTION: 'I requested a one-on-one meeting before the decision was finalised. I prepared a written comparison of the two approaches — covering maintainability, performance, and the impact on our existing infrastructure — and walked him through it during the meeting. I was explicit that I respected his experience and was open to being persuaded, but I wanted to make sure the trade-offs were visible before we committed.'
- RESULT: 'He appreciated the analysis. We agreed on a hybrid approach that addressed the timeline he needed while reducing the technical debt I was concerned about. That conversation also became a template for how our team raised technical objections going forward.'
Watch Out
Never say 'I was right and my manager was wrong' — even if you were. The interviewer is assessing how you handle the disagreement, not who won. Frame the outcome as a shared decision, not a victory.
For Question 4 — conflict within the team — the key addition is prevention. Strong candidates do not just describe how they resolved a specific conflict; they explain what they put in place so it was less likely to recur. A sentence like 'After that, I proposed we hold a brief architecture discussion at the start of each sprint so disagreements surfaced early' signals maturity.
Useful phrases for conflict answers
- 'I wanted to make sure we were deciding with full information, so I put together a comparison...'
- 'Rather than escalating, I suggested we prototype both approaches and let the data decide.'
- 'I listened to her reasoning first — I wanted to understand her concern before presenting mine.'
- 'We disagreed on the approach, but we agreed on the goal — so I framed the conversation around the goal.'
- 'The team ultimately went with her approach, and I committed to it fully once the decision was made.'
Failure and mistakes questions (with answers)
Failure questions are the ones most non-native engineers avoid or minimise — and that avoidance is exactly what interviewers notice. A candidate who cannot name a genuine failure either lacks self-awareness or is not being honest. Both are disqualifying signals.
The 5 failure and mistakes questions
- Tell me about a time you failed. How did you deal with it?
- Tell me about a time you missed a deadline. What happened, and how did you handle it?
- Describe a time you took a big risk and it failed.
- Describe a time you received tough or critical feedback.
- Tell me about a time you made a mistake that affected the team or the product.
Insight
The best failure answers follow a specific arc: the mistake was real, the response was immediate and owned, the fix was concrete, and the change in behaviour is permanent and specific — not 'I learned to be more careful.'
Model answer — failure (Q8)
- SITUATION: 'In a previous role, I was responsible for delivering a new feature ahead of a product launch. The deadline was tight, and I was under pressure to ship.'
- TASK: 'My job was to build the feature and make sure it was stable before it went to production.'
- ACTION: 'I rushed through the testing phase — I skipped several edge-case tests I would normally run, telling myself the core functionality was solid. The feature shipped, and within a few hours a critical bug surfaced that affected a significant portion of users. I immediately told my team lead, took ownership of the fix, and worked through the night to deploy a patch. I also ran a root cause analysis the following day to understand exactly which test would have caught it.'
- RESULT: 'The patch was live within 24 hours. More importantly, I changed my process: I now keep a non-negotiable test checklist that I do not compress regardless of deadline pressure. That change has prevented similar issues in every project since.'
Interview tip
The phrase 'I changed my process' is more credible than 'I learned my lesson.' It is specific and behavioural — it tells the interviewer the learning actually stuck.
For Question 9 — missed deadline — the key move is early communication. Interviewers know deadlines get missed; what they are testing is whether you told anyone before the deadline passed, or only after. An answer that includes 'as soon as I realised we were at risk, I told my manager and proposed a contingency plan' is far stronger than one where the miss comes as a surprise to everyone.
Useful phrases for failure answers
- 'I take full responsibility for that decision — I should have...'
- 'As soon as I realised the issue, my first step was to communicate it rather than try to fix it quietly.'
- 'I ran a root cause analysis to make sure I understood not just what went wrong, but why.'
- 'Since then, I have changed my approach specifically by...' — then name the concrete change.
- 'It was a difficult experience, but it is the one that has most changed how I work.'
Leadership and initiative questions (with answers)
Leadership questions do not require a formal management title — and interviewers at US and UK companies generally do not expect one. What they are testing is whether you identify problems without being asked, whether you move others toward a solution, and whether you can describe that influence clearly in English.
The 6 leadership and initiative questions
- Describe a time when you led a team. What was the outcome?
- Describe a situation where you saw a problem and took the initiative to correct it.
- Describe a time you went above and beyond the requirements for a project.
- Describe a time you went out of your comfort zone. Why did you do it?
- Describe a time you anticipated potential problems and developed preventive measures.
- Describe a time you delivered a project under a tight deadline.
For Question 14 — taking initiative — the structure that works is: name the problem you spotted (and why others might not have), explain why you decided to act rather than wait, describe exactly what you did, and quantify the result. The non-obvious part: name why the problem existed. 'Our deployment process had grown organically over two years and nobody owned it' is more credible than 'the process was inefficient.'
Model answer — initiative (Q14)
- SITUATION: 'Our team's deployment process required about a dozen manual steps — it had grown organically and nobody had ever formalised it. Each deployment took several hours and introduced errors roughly one in five times.'
- TASK: 'This was not my assigned responsibility, but I could see it was slowing down every engineer on the team, including me.'
- ACTION: 'I proposed automating it to my team lead, got approval, and spent two weeks outside my regular sprint work building a CI/CD pipeline. I selected the tooling, built it in a staging environment, tested it against our last ten deployments, and ran a short training session for the team before we switched over. I also wrote documentation so anyone could maintain it.'
- RESULT: 'Deployment time dropped from several hours to under twenty minutes, and error-related rollbacks essentially stopped. Management extended the same automation approach to two other teams. The more lasting impact was that engineers stopped dreading release days — which had a real effect on team morale.'
Watch Out
Avoid the phrase 'I am a natural leader' or 'I have always been a leader.' These are claims without evidence. Show the behaviour; let the interviewer draw the conclusion.
Useful phrases for leadership and initiative answers
- 'I noticed that nobody had ownership of this problem, so I decided to take it on.'
- 'I did not wait to be asked — I brought a proposal to my manager rather than a complaint.'
- 'I delegated based on each person's strengths rather than availability.'
- 'I kept the team informed at every stage so there were no surprises.'
- 'The outcome was X, but what I value more is that the team now has a process that prevents this class of problem entirely.'
Pressure and prioritisation questions (with answers)
Pressure questions test two things simultaneously: your technical judgment under stress, and your ability to communicate clearly when the stakes are high. The English challenge here is specific — when you are describing a high-pressure situation, there is a tendency to speak faster, use shorter sentences, and drop the connective tissue that makes an answer coherent. Slow down deliberately.
The 4 pressure and prioritisation questions
- Tell me about a time you worked well under pressure.
- Tell me about a time when you had to prioritise your tasks quickly.
- Describe a time when your workload was heavy and how you handled it.
- Provide an example of a time when you had to make a difficult decision.
Model answer — working under pressure (Q19)
- SITUATION: 'A major client reported a critical bug that was blocking their day-to-day operations. The bug needed to be resolved within 48 hours or we risked losing the account.'
- TASK: 'I was the engineer with the deepest knowledge of that part of the codebase, so the fix fell to me.'
- ACTION: 'My first step was to isolate the problem — I resisted the urge to start changing code immediately and spent the first hour reproducing the bug reliably and narrowing down the cause. Once I had identified a flaw introduced in a recent update, I built and tested the fix in a staging environment before touching production. I kept my manager updated every two to three hours so they could manage the client relationship in parallel.'
- RESULT: 'The fix was deployed well inside the 48-hour window. The client specifically mentioned our communication during the incident as a reason they renewed their contract. I also wrote a post-mortem that led to us adding a regression test for that category of bug.'
For Question 20 — prioritising quickly — the interviewer wants to see a framework, not just a story. Name the method you used to decide what to do first: urgency versus impact, stakeholder dependency, reversibility of the decision. 'I assessed which task had the highest business impact and the least reversibility if delayed' is more impressive than 'I made a list.'
Useful phrases for pressure answers
- 'Before I started fixing anything, I made sure I fully understood the problem — that saved time overall.'
- 'I communicated proactively throughout, so my manager was never in the dark.'
- 'I broke the work into the smallest possible deliverable chunks and set mini-deadlines for each.'
- 'I prioritised based on impact and reversibility — the irreversible decisions came first.'
- 'The pressure was real, but it did not change my process — if anything, it made me more disciplined about following it.'