Behavioral Interview Questions: 40+ Prompts Software Engineers Actually Get

Behavioral interview questions ask you to tell a real story from your work: Tell me about a time when… Give me an example of… Describe a situation where…

They are not trick questions. The interviewer is checking whether you have done the job before — owned a mess, disagreed without blowing up, shipped under a constraint, recovered from a miss — and whether you can explain it in a way another engineer would believe.

This is the list software engineers actually get in hiring-manager, bar-raiser, and “Googleyness” rounds, plus how to answer without sounding like a STAR worksheet.

If you already have stories and keep turning them into clichés, read how to tell your story without clichés after this. If you need the spoken warmup, Google’s old practice tool is gone — use the loop in Google Interview Warmup.

What are behavioral interview questions?

Behavioral interview questions are prompts about past behavior. The theory is boring and mostly true: the best predictor of how you will act on this team is how you acted on the last one.

They are different from:

Technical questions — code, design, debugging
Situational questions — “What would you do if…?” (hypothetical)
Fit questions — “Why this company?” / “Where do you see yourself?”

You can prepare. You cannot memorize forty unique epics. You need six stories you can retarget when the wording changes.

Why tech companies ask them

A coding round tells them you can solve a puzzle. A behavioral round tells them whether they want you in the on-call rotation.

At Google this shows up as Googleyness / leadership. At Amazon it is Leadership Principles, often with a bar raiser. At Meta it affects level. At almost every mid-size company, the hiring manager round is this conversation with extra product context.

They are scoring:

Ownership — did you drive it, or narrate the team’s work?
Judgment — was there a real choice, or only a happy path?
Collaboration — can you disagree and still ship?
Impact — did something measurable change?
Self-awareness — can you name what you would do differently?

If your answer has no fork in the road, it is a status update. They already have your résumé.

How to answer behavioral interview questions

Use STAR as anchors, not a script.

Piece	What to say	How long
Situation	Time, team, the concrete problem	1–2 sentences
Task	What you owned	1 sentence
Action	The choice, the steps, the trade-off	Most of the answer
Result	Number, change, or lesson	2 sentences

A shape that is easier to remember in the room:

Scene → Stake → Choice → Turn → Takeaway

Same content. Less “In this situation my task was…”

Rules that actually move the score:

Start in the scene. Not “In my last role as a backend engineer…”
Say I for your part. Name the team’s work as the team’s.
Make the choice visible. Two options, you picked one.
End with a number or a change in how you work. “It was successful” is not a result.
Stop at 90 seconds. Then let them ask the follow-up. The follow-up is the real interview.

Do not invent metrics. If you do not have a number, say what broke, what you stopped, or what you do differently now.

40+ behavioral interview questions (by what they are really asking)

You will not get all of these. You will get a rotation of the same eight themes. Prepare the theme, not the exact wording.

Ownership and delivery

Tell me about a time you owned something end to end.
Describe a project you are proud of. What was your contribution?
Tell me about a time you went beyond your job description.
Give an example of when you had to deliver with incomplete requirements.
Tell me about a time you missed a deadline. What happened next?
Describe a time you had too much on your plate. How did you prioritize?
Tell me about a time you had to say no to a stakeholder.

What they want: you set a bar, you cut scope on purpose, you did not hide a slip.

Conflict and disagreement

Tell me about a time you disagreed with a teammate.
Describe a conflict in a code review. How did you handle it?
Tell me about a time you disagreed with your manager.
Give an example of a time you had to convince someone of a technical approach.
Tell me about a time you were overruled. What did you do?
Describe a time you worked with someone whose style was very different from yours.

What they want: you argued about the problem, not the person. You changed your mind when you learned something. You committed after the decision.

Failure, mistakes, incidents

Tell me about a time you failed.
Describe a production incident you caused or helped cause.
Tell me about a time your initial solution did not work.
Give an example of a decision you made that was wrong.
Tell me about a time you received critical feedback. What did you change?
Describe a time you had to communicate bad news.

What they want: specific failure, your part, mitigation, prevention. No “the real failure was that I cared too much.”

Ambiguity and judgment

Tell me about a time you had to make a decision with incomplete data.
Describe a time you had two reasonable designs and had to pick one.
Tell me about a time requirements changed late.
Give an example of when you simplified a problem instead of adding complexity.
Tell me about a time you pushed back on a launch.

What they want: a trade-off you can name (latency vs cost, speed vs safety), and who you brought with you.

Leadership without a title

Tell me about a time you led without authority.
Describe a time you mentored someone.
Tell me about a time you raised the quality bar on the team.
Give an example of when you unblocked another team.
Tell me about a time you had to get multiple teams aligned.

What they want: influence, not “I was the scrum master.” Docs, prototypes, a pilot, a decision record.

Customers, users, and stakeholders

Tell me about a time you dealt with an unhappy partner or customer.
Describe a time you used data to change a product or technical decision.
Tell me about a time you had to explain a technical issue to a non-engineer.
Give an example of when user feedback changed your plan.

What they want: you treat the user as a constraint, not a slide. Engineers at product companies get this even if they never sat in support.

Pressure, time, and working style

Tell me about a time you worked under a tight deadline.
Describe a time you had to context-switch across several urgent issues.
Tell me about a time you improved a process (on-call, reviews, deploys).
Give an example of when you stayed motivated through a slog.

What they want: prioritization and a system, not “I just worked nights.”

Growth and self-awareness

Tell me about a time you had to learn something quickly.
Describe a time you were out of your depth. What did you do?
Tell me about a time you changed your mind about a technical belief.
What is a piece of feedback you still work on?
Tell me about a time you helped someone else get better, not just the code.

Same bank as above. If they ask “biggest weakness,” answer with a real one plus the system you put in place — not “I work too hard.”

Sample answers (software engineering)

These are templates. Swap in your own work. Do not recite them word for word.

Keep each answer to four beats: what happened → what I did → what changed → what I learned.

“Tell me about a time you disagreed with a technical decision.”

We were about to launch payments. A teammate wanted one shared retry for every API call. I thought that was risky — if a charge already went through, a retry could bill the customer twice. I was reviewing their pull request, not writing it. Instead of arguing in comments, I got on a call. They explained they were fixing timeouts they had already seen in staging. We agreed to retry only on the calls that needed it, and we added a test so a charge cannot run twice. It shipped the next day. No double charges. I now ask “what if this runs twice?” before we merge, not after we launch.

Why this works: a clear problem, you listened, you found a middle path, you say what you do now.

“Tell me about a production mistake.”

I pushed a config change that sent product search to a slow database copy. Checkout still worked. Search started timing out. It was my change, so I rolled it back in about fifteen minutes. Then I wrote a short timeline in Slack before I fully understood the root cause. After the incident I added a check so we cannot ship that config again, and I wrote a postmortem. It has not happened since. Lesson: treat config like code. Review it the same way.

Why this works: you owned the mistake, you fixed it first, then you stopped it from happening again.

“Tell me about a time you missed a deadline.”

We promised a ranking change for Tuesday. On Monday the tests looked fine, but we still had no way to turn the feature off if it went wrong. I told the PM we should slip one day rather than ship something we could not undo. We dropped a small UI tweak, kept the off switch, and launched Wednesday. Clicks went up a little. The PM was fine once I explained the risk in one message. I now build the off switch first, not last.

Why this works: you missed on purpose, you say why, and you still shipped something useful.

For hiring-manager rounds, stretch the same stories with one extra sentence of tension. The longer version is in effective storytelling in hiring manager interviews.

You need six stories, not forty answers

Map every question above onto a small set:

A delivery you drove — ownership, pride, going beyond the job
A conflict you resolved — code review, manager, other team
A miss — incident, bad decision, late launch
An ambiguous call — two designs, incomplete data, late requirement change
Influence — mentor, no-title lead, unblocking
A user or stakeholder moment — angry partner, data that changed the plan

Write each as five lines: scene, stake, choice, turn, takeaway. Not a script.

When they ask a new wording, reuse the story and change which choice you zoom into. The conflict story is also “disagreed with manager,” “code review,” and sometimes “persuasion.”

Company-specific flavor (same stories)

Amazon: they will ask the same questions in Leadership-Principle language (Ownership, Dive Deep, Disagree and Commit, Bias for Action). End with the result and what you would repeat.
Google: they listen for collaboration and how you handle ambiguity. Soft-pedaling conflict reads as low Googleyness, not as niceness.
Meta: they probe for impact and speed. If every story is a six-month design, add one that shipped in a week.
Everyone else: read the job post. If it says “cross-functional,” have the stakeholder story ready.

For the actual questions people reported last week, use recent interview questions or a company page such as Google interview questions. Behavioral lists on the internet are stable. The company’s current loop is not.

How to practice

Knowing the list is not practice.

Pick five questions from this page, including one you hope they will not ask (failure).
Answer each out loud once, standing, no notes, phone recording on.
Read the transcript. Circle every sentence that could belong to anyone.
Re-answer only the weak ones.
Add one follow-up you did not prepare: “What would you do differently?” If you cannot answer that, the story is a résumé bullet.

Thirty minutes. Same muscle as the old Google Interview Warmup tool, without the dead website.

FAQ

What are the most common behavioral interview questions?
Tell me about a time you had a conflict. Tell me about a failure. Tell me about a project you owned. Tell me about a time you had to prioritize. Tell me about a time you disagreed with your manager. Those five cover most loops.

How many behavioral interview questions should I prepare?
Prepare six stories, not a unique answer per question. Interviewers reword. You retarget.

How long should an answer be?
About 90 seconds. If they want more, they will ask. Long answers hide the choice.

Should I use the STAR method?
Yes, as a checklist in your head. No, as spoken labels. Do not say “Situation: … Task: …”

Are behavioral interview questions different for senior engineers?
The prompts look the same. The expected altitude changes: more org-level trade-offs, more “I was wrong,” more stories where you created leverage for other people.

Can I use a story from a previous company?
Yes. Prefer the last two years when you can. Older stories are fine if they are the clearest example of the theme.

Bottom line

Behavioral interview questions are a request for scenes, not adjectives.

Build six stories with a visible choice. Practice them out loud. When the wording changes, keep the scene and change the zoom.

That is the whole game. The 40 prompts above are the same eight themes in different clothes.