Behavioral interview STAR method

Many interviews include behavioral questions such as "Tell me about a time you disagreed with a teammate." Companies ask them because past behaviour predicts future behaviour. They want to see how you communicate, handle problems and learn.

The STAR method

A simple structure that keeps answers clear:

S, Situation: the context in one or two sentences.
T, Task: your responsibility or goal.
A, Action: what you did, step by step. This is the longest part.
R, Result: the outcome, ideally with a number, plus what you learned.

Aim for about two minutes per answer. Some people add an L for Lessons learned.

Example

Question: Tell me about a time you fixed a difficult bug.

Situation: Our checkout page occasionally charged customers twice. It happened only a few times a week, so nobody could reproduce it. Task: I was asked to find the cause because it was hurting customer trust. Action: I read the payment logs and noticed duplicate requests a few milliseconds apart. I suspected double clicks and slow responses. I added a request ID to the logs, reproduced it by throttling the network, and confirmed the button stayed clickable while the request was running. I disabled the button after the first click and added an idempotency key on the server so repeated requests could not create a second charge. I wrote a test for it. Result: Duplicate charges stopped completely over the next quarter, and refund requests from that cause dropped to zero. I also documented the pattern for the team's other payment flows.

(This is a sample structure. Use your own real experiences.)

Build a story bank

Do not memorise answers. Prepare 5 to 7 real stories that you can adapt to many questions. Cover:

A technical challenge you solved.
A mistake or failure and what changed afterwards.
A conflict or disagreement you handled.
A time you led or took initiative without being asked.
A project with a tight deadline or changing requirements.
A time you learned something quickly.
Receiving tough feedback.
A project you are proud of.

For each, write down the STAR points and the measurable result. Students and freshers can use university projects, internships, open source, hackathons, volunteering or part-time work.

Common questions and how to approach them

"Tell me about yourself." Give a short professional story: who you are now, what you have done that is relevant, why you want this role. About one to two minutes, not your life history.

"Why do you want to work here?" Research the company. Mention the product, the problems or the engineering culture, and connect it to your interests. Avoid generic flattery.

"Tell me about a conflict with a teammate." Show you listened, focused on the problem not the person, and reached a solution. Do not blame or badmouth anyone.

"Tell me about a failure." Choose a real but not disastrous one. Own it, explain what you did to fix it and what you changed so it will not happen again. Honest reflection is the point.

"What is your biggest weakness?" Pick a genuine, non-critical weakness and show the concrete steps you take to improve. Avoid fake ones like "I work too hard".

"How do you handle tight deadlines or pressure?" Describe prioritising, communicating early and agreeing scope, not working in silence.

"Tell me about a time you disagreed with a decision." Show you shared your view with evidence, respected the final decision and supported it.

"Where do you see yourself in five years?" Be honest about growth: deeper skills, more responsibility, and how the role helps.

Tips for strong answers

Say "I", not only "we". Make your own contribution clear, while giving credit to the team.
Include numbers where you can (time saved, errors reduced, users affected).
Keep it specific. Real details are more believable than general claims.
Be honest. Interviewers ask follow-up questions, and invented stories fall apart.
Be concise. If it takes five minutes, trim it.
End with the result and the lesson.
Stay positive about previous employers, teammates and managers.

Common mistakes

Rambling without a clear action or result.
Only describing the team's work, never your own part.
Answering with what you "would" do instead of what you did.
Blaming others.
No reflection or learning in failure stories.
Not preparing questions of your own.

Questions to ask the interviewer

Asking good questions shows interest and helps you judge the job:

What does success look like in the first six months?
How does the team do code review, testing and deployment?
What are the biggest technical challenges right now?
How do you support learning and mentoring?
How is feedback given and how are decisions made?

Preparing

Read the job description and note the skills they care about.
Match each skill to one of your stories.
Practise out loud, ideally with a friend or by recording yourself.
Prepare a short intro and your questions.
Sleep well. Be on time and ready for video call technology.

Takeaway: prepare a handful of real stories, structure each with STAR, focus on your actions and results, be honest about mistakes and learning, and ask thoughtful questions back.

Interview prep and DSA series, Part 2 (data structures and behaviour): 5 of 5. Previous: Dynamic programming for beginners: a step-by-step method.