30 Behavioral Interview Questions for Software Engineers (With STAR Answers)

Technical skill gets you shortlisted; behavioral rounds decide the offer — and the level. At many companies a strong coding round with a weak "tell me about a conflict" answer ends in a down-level or a no.

The good news is that behavioral questions are far more predictable than coding ones. Below are the 30 questions software engineers hear most, grouped by what they're really testing, with full example answers and a way to prepare that doesn't involve memorising thirty scripts.

First, the format: STAR

Every answer below follows STAR — Situation, Task, Action, Result. If you haven't used it before, read our STAR method guide. The short version:

• Situation (2–3 sentences): the context, just enough to follow.
• Task (1–2 sentences): what you were responsible for.
• Action (most of the answer): what you did, the options you weighed, why you chose one.
• Result (with a number): what changed, and what you learned.

1. Ownership and initiative

1. Tell me about a time you took ownership of something outside your role.
2. Describe a project you drove from start to finish.
3. Tell me about a time you noticed a problem nobody asked you to fix.
4. When have you gone beyond what was required?
5. Tell me about the work you're proudest of.

Example answer — "a problem nobody asked you to fix":

Situation: Our checkout service had a flaky integration test suite — about one in five CI runs failed randomly, and people had started re-running builds until they passed. Task: It wasn't assigned to anyone, but I was losing roughly an hour a day to it, so I took it on. Action: I pulled three months of CI results and found 80% of failures came from four tests sharing a single database fixture. I rewrote those tests to use isolated, per-test schemas, added a retry-free policy so flakiness would surface instead of hide, and wrote a short guide on the pattern for the team. Result: Random failures dropped from about 20% of runs to under 2%, median pipeline time fell by eleven minutes, and two other teams adopted the fixture pattern. I learned that "everyone's problem" usually means nobody's — it's worth asking who owns it before assuming someone does.

2. Conflict and disagreement

6. Tell me about a disagreement with a teammate. How did you resolve it?
7. Describe a time you disagreed with your manager.
8. Tell me about working with a difficult stakeholder.
9. When have you had to push back on a product requirement?
10. Tell me about a time you changed your mind.

Example answer — "disagreed with a teammate":

Situation: A senior colleague and I disagreed on whether to add caching to our search API or fix the underlying slow query first. The launch was three weeks out. Task: I was the engineer implementing the fix, so I needed us to converge quickly. Action: Instead of debating opinions, I proposed we each write down what would change our mind. I then profiled the endpoint: 70% of latency came from one missing index. I shared the flame graph, suggested we add the index first and revisit caching with real numbers, and asked him to review the index change, since he knew the schema best. Result: p95 latency dropped from 1.8s to 240ms with the index alone; we shipped without caching and avoided a cache-invalidation problem. More importantly, we started using the "what would change your mind?" question as a team habit.

Notice what the answer avoids: blaming the colleague, or "I was right." Interviewers are scoring how you disagree, not who won.

3. Failure and mistakes

11. Tell me about a time you failed.
12. Describe a bug you shipped to production.
13. Tell me about a missed deadline.
14. What's a piece of feedback that was hard to hear?
15. Tell me about a decision you'd make differently.

Example answer — "a bug you shipped":

Situation: I shipped a change to our notification service that deduplicated messages by user ID — and it silently dropped legitimate messages for users with multiple devices. Task: I'd written and deployed the change, so I owned the incident. Action: Within an hour of the first report I rolled back, then wrote a script to identify affected users from logs and re-sent roughly 4,000 missed notifications. In the post-mortem I owned the root cause — I'd tested with single-device accounts only — and added multi-device fixtures to our test data plus a canary metric on delivery counts. Result: No customer escalations after the re-send, and the canary metric caught a different delivery regression two months later before it reached users.

4. Ambiguity and prioritisation

16. Tell me about a time requirements were unclear.
17. How do you prioritise when everything is urgent?
18. Describe a time you had to make a decision without enough data.
19. Tell me about a project whose scope changed midway.
20. When did you have to say no to something?

5. Influence and leadership (even without a title)

21. Tell me about a time you influenced a decision without authority.
22. Describe mentoring someone.
23. Tell me about improving a team process.
24. When did you convince people to adopt a new tool or practice?
25. Tell me about leading a project with engineers from other teams.

6. Customer and business focus

26. Tell me about a time you used data to make a decision.
27. Describe a trade-off between quality and speed.
28. When did you advocate for the user?
29. Tell me about a feature that didn't achieve what you expected.
30. What's the most impactful thing you've built, and how did you measure it?

Six stories, thirty questions

You don't need thirty answers. You need six strong stories, each mapped to several questions:

Story	Answers questions like…
A technical project you drove end to end	2, 5, 25, 30
A disagreement you resolved well	6, 7, 10, 21
A real mistake with a real fix	11, 12, 15
A time you worked through ambiguity	16, 18, 19
A process or tool you improved	3, 23, 24
A data-driven or user-focused decision	26, 27, 28

For each story, write the STAR outline in bullet points (not prose), add one number to the Result, and practise it out loud in about two minutes.

Mistakes interviewers mark down

• "We" all the way through. They're hiring you. Say what you did.
• Too much Situation. If you're 60 seconds in and still setting context, cut.
• No trade-off. Strong answers mention the option you didn't choose and why.
• Fake failures. "I care too much" loses trust instantly.
• No lesson. Especially for failure and conflict questions, end with what changed afterwards.

Related reading

• Tell me about yourself: answers for software engineers
• The STAR method, and where AI actually helps
• What FAANG and top India tech loops look like