Behavioural interview questions for software engineers: STAR answers with examples

Behavioural questions ask how you have handled real situations: a conflict, a deadline, a mistake. Interviewers use them to predict how you will work with their team, and they often weigh them as heavily as the coding rounds. The good news is that they are the most predictable part of any interview. This guide covers the STAR method, the questions engineers are asked most, worked example answers you can adapt, and how to rehearse them out loud.

The STAR method

STAR gives every answer the same clear shape:

• Situation: the context, in one or two sentences. Where you were and what was going on.
• Task: what you were responsible for, or the problem that needed solving.
• Action: what you did, step by step. This is the core of the answer and should take about half the time.
• Result: what happened, with a number if you have one, and what you learned.

Aim for 90 seconds to two minutes per answer. Shorter sounds thin; longer loses the interviewer. Say “I”, not “we”: the interviewer is assessing you, not your team.

Build a story bank first

You do not need a separate story for every possible question. Prepare six to eight stories from your projects, internships, studies or previous jobs, and practise bending each one to several questions. Good stories to have ready:

1. A technical problem you solved that was hard.
2. A disagreement with a teammate or manager.
3. A mistake you made, and what you changed afterwards.
4. A tight deadline or a change in priorities.
5. A time you led something, even informally.
6. A time you learned something new quickly.
7. A time you helped someone else succeed.
8. Feedback you received and acted on.

For each story, write the four STAR parts as bullet points, not a script. A script sounds recited; bullets keep it natural.

The questions engineers are asked most

• Tell me about yourself.
• Tell me about a challenging technical problem you solved.
• Tell me about a time you disagreed with a teammate. How did you resolve it?
• Tell me about a mistake you made.
• Describe a time you had to meet a tight deadline.
• Tell me about a time you had to learn something quickly.
• Tell me about a project you are proud of.
• Tell me about a time you received critical feedback.
• Describe a time you had to make a decision with incomplete information.
• Why do you want to work here?

Example answers

These are examples to show the structure. Replace every detail with your own experience: interviewers can tell when a story is not real, and follow-up questions will expose it.

“Tell me about a challenging technical problem you solved.”

• Situation: “In my final-year project we built a booking app, and a week before the demo the search page took eight seconds to load.”
• Task: “I owned the backend, so finding and fixing the slowdown was my job.”
• Action: “I timed each step of the request and found the database was scanning the whole bookings table for every search. I added an index on the two columns we filtered by, rewrote the query to fetch only the fields the page used, and added a test that failed if the query time went above 200 milliseconds.”
• Result: “The page loaded in under half a second, and the test caught a regression two weeks later. Since then I measure before I optimise, instead of guessing.”

“Tell me about a time you disagreed with a teammate.”

• Situation: “During an internship, a teammate wanted to rewrite our payment module from scratch; I thought a rewrite was too risky with the release a month away.”
• Task: “We needed a decision both of us could support, without slowing the team down.”
• Action: “Instead of arguing opinions, I suggested we list the bugs that were driving the rewrite. Most came from one function. We agreed to refactor that function with tests first and revisit the rewrite after the release.”
• Result: “The refactor fixed four of the five open bugs and we shipped on time. My teammate later led the rewrite with a proper plan, and I learned to turn disagreements into shared evidence.”

“Tell me about a mistake you made.”

• Situation: “On a group project I merged a change that broke sign-in for everyone the evening before a review.”
• Task: “I had to fix it fast and make sure it could not happen the same way again.”
• Action: “I reverted the change within minutes, told the team what had happened, then found the cause: I had tested locally with an old configuration. I fixed the change, and I set up a check that ran the sign-in tests on every pull request.”
• Result: “Sign-in was back within half an hour and the review went ahead. The check caught two similar problems later in the term. I now run the full test suite before merging anything that touches authentication.”

Notice what the mistake answer does: it owns the mistake plainly, spends most of the time on the fix and the prevention, and ends with a lasting change. Never pick a “mistake” that is really a strength in disguise; interviewers see through it.

“Tell me about yourself.”

This is not a STAR question, but it opens most interviews, so prepare it the same way. Use present, past, future in about 60 to 90 seconds:

• Present: what you do now and what you are focused on.
• Past: one or two experiences that led here, with a concrete result.
• Future: why this role is the next step, tied to something specific about the company.

How to rehearse

Knowing your stories is not the same as telling them well under pressure. Rehearse them the way you will deliver them:

1. Say them out loud. Reading bullets silently does not train speaking. Practise each story aloud at least three times.
2. Time yourself. If an answer runs past two minutes, cut the situation, not the action.
3. Record one session. Listen for filler words, missing results and too much “we”.
4. Run mock interviews. Ask a friend or mentor to pick questions you have not seen and to ask one follow-up after each answer: “What would you do differently?” or “How did you measure that?”.
5. Mix behavioural and technical practice. Real loops switch between them, so practise switching too.

Our guide to practising for live technical interviews covers mock interviews in more depth, including how to use AI tools to rehearse within the rules.

Mistakes to avoid

• No result. Every answer should end with what changed. If you have no number, describe the outcome.
• All “we”. Make your own contribution clear.
• Blaming others in conflict or failure stories.
• Memorised scripts. Rehearse the structure, not the exact words.
• Invented stories. Follow-up questions go two or three levels deep. Use real experiences, however small.

Summary

Prepare six to eight real stories, structure each with STAR, keep answers under two minutes, and rehearse them out loud with someone asking follow-up questions. Behavioural rounds are the most predictable part of the interview, so a few hours of spoken practice gives a large return.