Behavioral Interview Questions for Developers (With STAR Examples)

Behavioural interviews ask about how you have handled real situations in the past, on the principle that past behaviour predicts future behaviour. Many developers prepare hard for coding rounds and then improvise these questions, which is a mistake: they often decide close calls, especially for mid-level and senior roles.

The STAR method#

Structure each answer in four parts:

• Situation: the context, briefly.
• Task: what you were responsible for.
• Action: what you did (the most important part, so say "I", not just "we").
• Result: what happened, ideally with a measurable outcome, and what you learned.

Keep each answer to about two minutes. Spend most of the time on the Action.

Prepare six stories, not fifty answers#

You can't predict every question, but most behavioural questions fall into a few themes. Prepare one or two real stories for each:

1. A technical challenge you solved.
2. A mistake or failure and what you learned.
3. A disagreement with a colleague or manager.
4. A time you took ownership beyond your role.
5. A time you dealt with a tight deadline or changing requirements.
6. A time you helped or mentored someone.

Each story can be adapted to several questions.

Common questions and example answers#

The examples below show the structure. Use your own real experiences: interviewers ask follow-up questions, and invented stories fall apart quickly.

"Tell me about a time you made a mistake."#

Situation: We were releasing a change to how our app calculated delivery fees. Task: I had written the change and the tests. Action: I missed an edge case for orders with zero-priced items, and a small number of customers were charged incorrectly after release. I noticed the pattern in the logs the next morning, told my lead immediately, rolled back the change, and worked with support to refund the affected orders the same day. Then I added tests for the missing cases and proposed a checklist step for pricing changes in our pull request template. Result: All affected customers were refunded within a day, and the checklist has caught similar issues since. I learned to test boundary values deliberately, not just the common path.

What interviewers look for: honesty, ownership, a fast and calm response, and a lasting fix.

"Describe a disagreement with a teammate."#

Situation: A teammate wanted to add a new database for one feature; I thought our existing one could handle it. Task: We needed to agree on a design before the sprint started. Action: Instead of arguing in comments, I suggested we each write down the requirements, costs and risks. I built a small prototype on our existing database to test the main query under realistic load and shared the numbers. We discussed it with our lead with both options on the table. Result: The prototype showed the existing database was fast enough for the expected volume, so we avoided running a new system. My teammate's concerns about future growth were valid, so we agreed on a threshold at which we'd revisit the decision.

What they look for: respect, using evidence, and finding the best outcome rather than "winning".

"Tell me about a time you went beyond your role."#

Good stories: fixing a flaky test suite nobody owned, improving onboarding documentation, setting up monitoring after an incident, or organising knowledge-sharing sessions. Show what problem you noticed, why it mattered, what you did and the result.

"How do you handle tight deadlines?"#

Show that you communicate early, cut scope sensibly and protect quality where it matters: "I list what's essential for the deadline, agree with the product owner what can move to a follow-up release, and flag risks early instead of the day before." Then back it up with a short real example.

"Why do you want to leave your current job?"#

Stay positive and forward-looking: "I've learned a lot there, especially about X. I'm looking for more ownership of Y / a product company / remote work with an international team, which is what this role offers." Never criticise your current employer, even if it deserves it.

Questions for senior candidates#

Senior candidates also get questions like these:

• Tell me about a technical decision you'd make differently now.
• How have you influenced a decision you didn't have authority over?
• How do you mentor less experienced engineers?
• Describe a time you had to push back on a product or business request.

Tips#

• Use "I" for your actions. It's fine to credit the team, but the interviewer is assessing you.
• Be specific. "We improved performance" is weak; "I found the N+1 query causing slow page loads and cut load time from 4 seconds to under 1" is strong.
• Include what you learned, especially in failure stories.
• Practise out loud with a friend, or record yourself.

Key takeaways#

• Behavioural answers often decide close calls; prepare for them.
• Use STAR and spend most of each answer on your own actions.
• Prepare six real stories that cover the common themes.
• Be honest, specific and positive, and show what you learned.

Next, prepare a strong opening with how to answer "tell me about yourself", and see the full interview process.

#interviews

DT

Written by

devlk Team

Editorial team

The devlk team writes practical career guides for software developers: salaries, interviews, remote work and getting paid from abroad.