Software Engineer Behavioral Interview Questions

Software engineer behavioral interview questions grouped by competency, with 20 real prompts, two full model answers, and a structure that survives follow-ups.

Software engineer behavioral interview questions test how you work, not whether you can code. They come as “tell me about a time” prompts and they are usually scored by a separate interviewer on a separate rubric from your coding rounds. At most large tech companies you will face at least one dedicated behavioral round, and behavioral probes are also mixed into system design and hiring manager calls. The competencies repeat: ownership, conflict, ambiguity, failure, technical judgement, and influence without authority. Amazon makes this explicit and asks candidates to prepare against its published Leadership Principles. Google, Meta, Stripe and most scale-ups use the same shape with different labels. The fix is not more stories. It is five or six well built stories, each written so it can be re-aimed at four or five different questions, and each carrying a number you can defend under follow-up.

TL;DR

Prepare five to six deep stories, not twenty shallow ones. Each story should answer four or five different prompts.
Use STAR: Situation, Task, Action, Result. Say “I” and not “we” in the Action section.
Amazon publishes 16 Leadership Principles and asks candidates to prepare against them. Map two stories to each of the four or five most likely ones.
Engineers lose points on Result, not Situation. Every story needs a measurable outcome and a “what I would do differently”.
Expect three to five follow-up questions per story. If your story only has one layer of detail, it collapses.
Rehearse out loud and timed. Aim for two to four minutes for a first answer, then let the interviewer pull more.

What competencies do engineering behavioral interviews actually score?

Interviewers are filling in a rubric, not having a chat. Almost every engineering behavioral rubric reduces to six buckets. Knowing the bucket tells you what the story must prove.

Competency	What the interviewer wants to see	Typical prompt opener
Ownership	You fixed something nobody assigned to you	“Tell me about a time you went beyond your scope”
Conflict and influence	You changed a decision without authority	“Tell me about a disagreement with a colleague”
Ambiguity	You made progress without a spec	“Tell me about a project with unclear requirements”
Failure and learning	You name a real mistake and the change it caused	“Tell me about a time you failed”
Technical judgement	You traded off correctly and can defend it	“Tell me about a hard technical decision”
Delivery under pressure	You cut scope instead of missing the date	“Tell me about a tight deadline”

Build one story per bucket, then check whether any story can cover two. That is your set. If you want a broader treatment of the format itself, the behavioral interview questions and answers guide covers the general question bank across roles.

What are the 20 questions to prepare?

These are the prompts that recur across engineering loops. Group them by competency so you can see which stories are doing double duty. You can run five free timed questions for your role to hear how your answers sound under a clock before you rehearse the full set.

Ownership and impact

Tell me about a project you owned end to end.
Tell me about a time you fixed something that was not your responsibility.
Tell me about a time you found a bug in production. What did you do first?
Describe a time you improved a system nobody had asked you to improve.

Conflict and influence

Tell me about a time you disagreed with your tech lead. What happened?
Describe a code review that turned into a real argument.
Tell me about a time you had to convince a product manager to change scope.
Describe a time you had to work with someone whose style clashed with yours.

Ambiguity and problem solving

Tell me about a project where the requirements kept changing.
Describe a time you had to debug something you did not understand.
Tell me about a decision you made with incomplete information.

Failure and learning

Tell me about a time you shipped something that broke.
Describe your biggest technical mistake and what changed after it.
Tell me about feedback that was hard to hear.

Technical judgement

Walk me through a design decision you would make differently now.
Tell me about a time you chose the boring technology over the interesting one.
Describe a time you paid down technical debt. How did you justify it?

Delivery and collaboration

Tell me about a deadline you were going to miss. What did you do?
Describe a time you mentored or unblocked another engineer.
Tell me about a time you had to say no to a request.

For the failure bucket specifically, the tell me about a time you failed answer guide walks through the trap of picking a fake failure. For the conflict bucket, see the conflict with a coworker interview answer guide.

How should you structure an engineering STAR answer?

The University of Colorado career handout describes STAR as Situation, Task, Action, Result, and notes the premise: past behaviour in a similar situation is the most accurate predictor of future performance. That premise explains what interviewers cut points for. Hypothetical answers score zero because they predict nothing.

Engineers get three parts wrong in a predictable order.

Situation runs too long. Two sentences. Name the system, the team size, and the stake. The interviewer does not need your company’s org chart.

Action uses “we”. The rubric scores you, not your team. Say what you personally did: the code you wrote, the meeting you called, the data you pulled, the person you talked to. If a sentence starts with “we decided”, rewrite it as “I proposed X, and after Y the team agreed”.

Result has no number. Latency, error rate, hours saved, incidents avoided, tickets closed. If the number does not exist, use a verifiable outcome instead: the design was adopted, the on call rotation stopped paging, the migration finished before the deprecation date.

A useful split for a three minute answer is roughly 20 seconds of Situation and Task, 100 seconds of Action, and 40 seconds of Result plus reflection. The STAR method interview examples guide has more worked structures.

What does a strong answer sound like?

Model answer 1: “Tell me about a time you disagreed with a technical decision”

My team was building a notification service and the tech lead proposed we write our own retry and dead letter queue on top of Postgres, because our existing message broker was owned by another team and had a slow onboarding process. I thought that was the wrong trade. My job was to deliver the service in a quarter, and I believed the custom queue would take most of that quarter and then become our permanent maintenance burden.

Rather than argue in the design review, I asked for three days. I built a throwaway prototype on the shared broker and measured the real onboarding cost, which was two days of paperwork, not the two weeks we had assumed. I also wrote a one page comparison with three columns: build time, on call surface, and the failure modes each option would introduce. I took it to the tech lead privately first, because I did not want the review to become a public referendum on his idea.

He changed the recommendation himself in the review. We shipped the service five weeks into the quarter instead of eleven, and the notification path has never appeared in our on call rotation since. What I took from it is that a prototype and a cost table move a senior engineer far faster than a strong opinion does.

Why this works: the disagreement is technical and specific, the candidate does the unglamorous work of measuring instead of debating, the private-first move shows judgement about people, and the result has two numbers plus a durable lesson.

Model answer 2: “Tell me about a time you shipped something that broke”

I owned a change to how we cached user permission checks. In staging it cut our p95 response time by about 40 percent, so I rolled it out on a Thursday afternoon. Within an hour support reported that a small number of users could see a settings page they should not have had access to. The cache key I had chosen did not include the organisation identifier, so a user who belonged to two organisations could get the wrong permission set.

I rolled back within eleven minutes of the first report and posted in the incident channel before I started diagnosing, because I wanted support to be able to answer customers rather than wait on me. Then I pulled the access logs and worked out the exact blast radius, which was 34 users across four organisations, none of whom had taken a write action on the wrong data. I wrote that up honestly in the postmortem including the fact that I had shipped a permissions change late on a Thursday with no gradual rollout.

Two things changed. I added the organisation identifier to the key and shipped it behind a one percent rollout. And I proposed a rule the team adopted: any change touching authorisation goes out on a Monday or Tuesday, behind a flag, with a stated rollback trigger. What I learned is that the speed of your rollback matters more than the elegance of your fix.

Why this works: it is a real failure with a real security dimension, the candidate does not hide the bad judgement call, the blast radius is quantified rather than hand waved, and the fix produces a team level change and not just a personal resolution.

How do you prepare against a published rubric like Amazon’s?

Amazon publishes 16 Leadership Principles on its careers site, including Customer Obsession, Ownership, Invent and Simplify, Dive Deep, Have Backbone: Disagree and Commit, and Deliver Results. Amazon’s own hiring pages describe an interview loop where several employees each assess different aspects of your skills, and they point candidates at the Leadership Principles and the STAR method as preparation.

Practically, that means two things for an engineer.

First, map before you write. Take your five or six stories and mark which principles each one can serve. A story about rewriting a slow batch job can serve Dive Deep, Invent and Simplify, and Deliver Results. Aim for two credible stories per principle you expect to be asked about, so you are not forced to repeat yourself in a loop where interviewers compare notes.

Second, prepare for depth. Dive Deep means the interviewer will ask what the actual query plan was, what the p99 looked like, why you rejected the other option. Write a second layer of detail under each story: the numbers, the names of the tools, the alternative you did not pick. If you cannot answer three follow-ups, the story is not ready.

How many rehearsals does this take?

Reading your stories is not preparation. Saying them out loud is. The gap between a story that reads well and a story that sounds good at minute 45 of a loop is large and only closes with repetition.

Stage	What you do	Time
Draft	Write 5 to 6 stories in STAR form, bullet points only	90 minutes
Add depth	Second layer of numbers, tools, rejected alternatives	60 minutes
Say it	Record yourself answering each prompt cold, no notes	45 minutes
Trim	Cut Situation, expand Action, add the reflection line	30 minutes
Pressure test	Have someone ask three follow-ups per story	60 minutes

A mock interview practice online session is the cheapest way to run that last stage, because the follow-ups are the part you cannot rehearse alone.

Frequently Asked Questions

How many stories do I need for an engineering loop?

Five or six deep ones. A four round loop with a behavioral component in each round will consume three to five stories, and interviewers do compare notes, so repeating one story twice is noticeable. Depth beats breadth because follow-up questions kill shallow stories.

Can I use a story from a personal project or an internship?

Yes, if it had real stakes and other people involved. A side project with users, a hackathon with a deadline, an open source contribution that required a maintainer to agree with you: all of these work. A tutorial you followed alone does not, because there was no judgement call in it.

What if I have never had a real conflict at work?

You almost certainly have. Conflict in the rubric sense means a disagreement about a decision, not a shouting match. A code review where you pushed back on an approach, a scope negotiation with a product manager, a time you told someone their design would not scale: any of those qualify.

Should I say the numbers if I am not certain of them?

Say the number and label the uncertainty. “Roughly 40 percent” or “about 30 users” is fine and honest. Inventing a precise figure is dangerous because interviewers ask how you measured it, and a fabricated number falls apart in one follow-up.

Do senior engineers get different questions?

Same questions, higher bar on scope and influence. A junior candidate can pass with a story about fixing their own bug. A senior candidate is expected to show impact across teams: a decision they changed, a standard they set, an engineer they grew.

How long should each answer be?

Two to four minutes for the first pass, then let the interviewer pull more with follow-ups. Answers under a minute read as thin. Answers over five minutes without a question in between mean you are not reading the room.