Top 20 Behavioral Interview Questions for Software Engineers (With STAR Examples)

I was sitting across from a candidate — a senior engineer, strong resume, crushed the coding round — and I asked him a simple question: “Tell me about a time you disagreed with a technical decision on your team.”

He paused. Looked up. Then said, “I mean, I generally try to keep things professional and find consensus.”

That was it. That was the whole answer.

I waited. He waited. We both waited. Then I moved to the next question. And I already knew the debrief wasn’t going to go well for him.

This was maybe three years ago, and I’ve seen some version of it happen dozens of times since. Engineers who spend weeks grinding LeetCode and studying system design, and then walk into the behavioral round with zero preparation. Like it’s a formality. A warm-up chat before the “real” stuff.

It’s not. I’ve personally seen behavioral rounds eliminate otherwise excellent candidates. And I’ve seen people with shaky coding skills get offers because they told stories that made the whole panel lean forward.

Here’s the thing: behavioral questions are predictable. Not in a bad way — in a “you can genuinely prepare for 80% of what you’ll be asked” way. The questions repeat. The themes repeat. And if you know the framework, you can walk in ready.

So let’s go through the 20 questions I see most often, how to think about each one, and how to not end up like my silent senior engineer friend.

The STAR method, quickly

You’ve probably heard of STAR. Situation, Task, Action, Result. It’s not complicated, and that’s sort of the point — it gives your answer a skeleton so you don’t ramble into oblivion.

• Situation — set the scene. Where were you, what was the project, what was the context? Two or three sentences max.
• Task — what was your specific responsibility or challenge? Not the team’s. Yours.
• Action — what did you actually do? This is the meat. Be specific. “I gathered data” is weak. “I profiled the API endpoints, identified that 80% of latency came from three queries, and proposed a caching layer to the team” is strong.
• Result — what happened? Quantify if you can. “We reduced response time by 40%.” If the outcome wasn’t great, say what you learned. Honest reflection scores higher than a fake happy ending.

The biggest mistake people make with STAR isn’t structure. It’s spending three minutes on Situation and thirty seconds on Action. Flip that ratio. The Action is what they’re evaluating.

If you want to go deeper on how behavioral scoring works and the common traps, I wrote a separate piece on behavioral interview mistakes that covers the scoring side.

The 20 questions, grouped by theme

I’ve grouped these by what they’re actually testing. The themes repeat across companies, even if the exact wording changes. If you prep two solid stories per theme, you’ll be able to answer most of what they throw at you.

Teamwork & collaboration

1. Tell me about a time you worked on a cross-functional project.

They want to hear that you can operate outside your engineering bubble. Talk about how you communicated with non-technical stakeholders. Did you adjust your language? Did you build alignment on tradeoffs? A good answer shows you understand that shipping software is a team sport that extends beyond the codebase.

2. Describe a situation where you had to help a struggling teammate.

This one reveals empathy and mentorship instincts. Don’t frame it as “I fixed their problem.” Frame it as “I helped them find the path.” Talk about pairing sessions, code reviews where you explained the reasoning, or how you created documentation that helped onboard them.

3. Give me an example of a time you had to collaborate with someone whose working style was very different from yours.

They’re testing adaptability. Maybe you’re async and they’re sync. Maybe you plan and they dive in. The key is: what did you do to bridge the gap? Not “they were wrong and I tolerated it.” More “I realized we needed a shared process, so I proposed X.”

4. Tell me about a time you received critical feedback.

Resist the urge to pick something trivial. “Someone told me I should comment my code more” is not a compelling story. Pick real feedback that stung a little. Show that you sat with it, extracted the useful part, and changed your behavior. Growth mindset, demonstrated through action.

Conflict & disagreement

5. Describe a time you disagreed with a technical decision.

The classic. Every company asks some version of this. Structure it: what was the decision, what was your position, how did you make your case, what happened? The critical thing: show that you advocated with data, not ego. And if you lost the argument, show that you committed anyway. “Disagree and commit” is literally an evaluation criterion at some companies.

6. Tell me about a time you had a conflict with a manager or tech lead.

Tread carefully but honestly. They’re looking for professional maturity. You escalated through the right channels. You separated the person from the problem. You didn’t go over their head first. If the conflict resolved, explain how. If it didn’t, explain what you learned about working with different leadership styles.

7. Give me an example of a time you pushed back on a requirement.

Product vs engineering tension is universal. The winning answers show that you understood the business goal behind the requirement, and that your pushback was constructive — “here’s why this is risky, and here’s an alternative that achieves 90% of the goal at 30% of the cost.” Not just “I said no.”

8. Tell me about a time you had to manage competing priorities from different stakeholders.

This is about communication and prioritization, not heroics. Good answers show a framework: you assessed impact, communicated tradeoffs transparently, and got explicit alignment before proceeding. The worst answer is “I just worked really hard and did everything.”

Leadership & ownership

9. Describe a project you drove from start to finish.

Even if you’re not a lead, they want to see initiative. Talk about how you scoped it, how you broke it down, how you handled roadblocks. Mention the unglamorous parts — the stakeholder alignment, the documentation, the handoff. Those details signal real ownership, not just coding.

10. Tell me about a time you had to make a decision without complete information.

Every senior-level behavioral round includes this. The framework: what information did you have, what was missing, how did you assess the risk, and what was your decision-making process? Show that you acted deliberately despite uncertainty, not that you guessed and got lucky.

11. Give me an example of when you mentored someone.

You don’t need to be a formal mentor. Code reviews count. Helping a junior debug something counts. Running a tech talk counts. What they’re looking for is: did you invest time in someone else’s growth without being asked?

12. Describe a time you identified a problem no one else noticed.

This is about proactive thinking. Maybe you spotted a security issue during a code review. Maybe you realized a migration plan had a gap. The stronger the “nobody was looking at this” factor, the better. And make sure to explain what you did about it, not just that you noticed.

Failure & learning

13. Tell me about a time you failed.

The question everyone dreads and almost everyone answers wrong. Don’t pick something where you were the hero who caught the problem early. Pick an actual failure. A deploy that broke production. A wrong architectural call. A missed deadline because you underestimated complexity. Then — and this is the whole point — explain specifically what you changed as a result. “I learned to be more careful” is nothing. “I implemented pre-deploy smoke tests for our team that caught three incidents in the next quarter” is everything.

14. Describe a time a project didn’t go as planned.

Similar to the failure question, but more about adaptability than personal accountability. How did you adjust? Did you re-scope? Did you communicate the delay early? Did you figure out what could still be delivered? Show the pivot, not the panic.

15. Tell me about a time you made a mistake that affected the team.

The trust test. They want to see that you owned it, communicated it, and fixed it without hiding. If you tried to cover it up initially, honestly saying that (and that you learned from it) is better than a sanitized version.

16. Give me an example of a time you had to learn something quickly under pressure.

This comes up a lot in fast-moving environments. New tech stack, unfamiliar codebase, production issue in a system you’ve never touched. The answer framework: what was the pressure, how did you approach learning (documentation? asking the right people? reading the code?), and how quickly did you become effective?

Technical challenges & problem-solving

17. Describe the most complex technical problem you’ve solved.

Pick something where the complexity wasn’t just algorithmic. Cross-service issues, debugging race conditions, untangling legacy code with no documentation — real-world complexity. Walk through your debugging process step by step. Show systematic thinking, not heroic intuition.

18. Tell me about a time you had to make a significant technical tradeoff.

Performance vs readability. Speed to market vs long-term maintainability. Build vs buy. The key: show that you evaluated both sides with data, involved the right people, and made a defensible decision. Even if it turned out to be the wrong one.

19. Give me an example of a time you improved a process or system.

Not a rewrite — an improvement. Maybe you set up CI/CD for a team that was deploying manually. Maybe you introduced code review guidelines. Maybe you automated a painful testing workflow. Show initiative and follow-through.

20. Describe a time you had to work under a very tight deadline.

They’re not looking for “I worked 80-hour weeks.” They’re looking for prioritization, tradeoff communication, and the ability to deliver something meaningful even when you can’t deliver everything. Talk about what you cut, why, and how you communicated that.

Common mistakes

I’ve been on enough debrief calls to see the patterns. Here’s what kills people:

Staying hypothetical. “I would usually…” means nothing. They need “I did.” Specific situation, specific actions, specific result. Every time.

Telling team stories in first person plural. “We decided to…” for three minutes straight. They’re interviewing you, not your team. Say what you did. It’s not bragging. It’s answering the question.

Picking “safe” failures. “My biggest failure was caring too much about code quality.” Come on. Pick a real one. The interviewer knows a dodge when they hear it.

Going long without structure. Five-minute meandering stories where the point arrives at minute four. Use STAR. Get to the Action within sixty seconds. That’s where the scoring happens.

Forgetting the Result. You told a great story and then… trailed off. Always land the plane. What was the outcome? What changed? What did you learn?

If any of these sound familiar, I broke them down in more detail in 5 behavioral interview mistakes that cost you the job.

Stuff people always ask me

How many stories do I actually need to prepare?

Eight to ten, and they should cover multiple themes each. A good conflict story might also work for a leadership question. A failure story might double as a technical challenge story. Map your stories to the five themes above and make sure there’s overlap. You don’t need twenty unique stories for twenty questions.

Should I memorize my answers?

God, no. Memorized answers sound memorized. Prepare the key beats — the Situation setup, the core Action details, the quantified Result — and then tell it naturally each time. It’ll come out slightly different every time, and that’s fine. That’s what makes it sound real.

What if I don’t have a story for one of these?

You probably do, you just haven’t framed it yet. That “disagreement” might have been a Slack thread where you argued for a different API design. That “failure” might have been a sprint where you over-committed. Go through your last two or three projects and extract moments. They don’t need to be dramatic.

Does practicing with someone actually help?

More than anything else. When I finally did mock interviews for behavioral rounds — not just technical ones — my answers went from rambling to sharp in about three sessions. Hearing yourself out loud is completely different from rehearsing in your head. Find a friend, a colleague, or a practice partner and run through these. The awkwardness fades fast.

The behavioral round isn’t a personality test. It’s a structured evaluation with predictable questions and clear scoring criteria. Treat it like any other technical skill: learn the framework, practice with real stories, get feedback, iterate. And if you’re building a broader prep plan that covers coding and system design too, take a look at how to prepare for a technical interview — it lays out the full picture.

Your past experience is the material. STAR is the structure. Preparation is the differentiator.

Ready to practice? Join the early access community —>