Behavioral interviews

Behavioral rounds — "tell me about a time when…" — often decide the final outcome and the level you're offered. Two candidates with equal technical rounds can be offered mid-level and senior roles purely on how they describe their past work. These questions aren't small talk: they're structured probes for evidence of how you behave on a team, scored against a rubric, and the best predictor of future behaviour is past behaviour. This lesson covers what interviewers listen for, how to build a story bank, the STAR structure, the common question families, and the mistakes that cost offers.

#What's being assessed

Companies phrase their values differently, but behavioral rubrics for engineers mostly assess the same handful of traits:

The same story can be told at very different levels. "I implemented the caching layer my lead designed" is mid-level. "I noticed checkout latency was hurting conversion, measured it, proposed caching promotions, got buy-in from two teams, and led the rollout — conversion rose 2%" is senior. Scope, initiative and measurable impact are what move you up.

#Build a story bank

Don't improvise. Before interviews, write down 8–10 true stories from your work (or projects, internships and study if you're early in your career), each covering several traits. Good sources:

• The project you're proudest of.
• A production incident you handled.
• A time you disagreed with a teammate, lead or product manager.
• A mistake you made, and what you did about it.
• A time you helped someone else grow or get unblocked.
• A time you changed a process, tool or habit on your team.
• A deadline you nearly missed, or missed.
• A time you had to learn something quickly.
• A decision you made with incomplete information.

For each story, note the situation, your specific actions, the measurable result, and which questions it could answer. Then map stories to the company's stated values, so you can pick the right one quickly in the interview.

#Tell it with STAR

STAR — Situation, Task, Action, Result — keeps a story focused and gives the interviewer what they need to score it. Spend your time where the evidence is:

• Situation (10%) — just enough context: team, system, stakes.
• Task (10%) — what you were responsible for, or the problem you saw.
• Action (60%) — what you did, step by step, and why. This is where the scoring happens.
• Result (20%) — the outcome, with numbers if possible, and what you learned.

A weak answer to "Tell me about a time you improved a system's reliability":

We had a lot of incidents with our order service, so the team added retries and monitoring and things got better.

A strong one:

Situation: At my previous company I worked on the order service for a food-delivery app. In one quarter we had six incidents where orders got stuck after the payment provider timed out. Task: I wasn't on call that week, but I volunteered to find the root cause because the incidents kept waking the team up. Action: I pulled the traces for all six incidents and found the same pattern: we retried payment captures without an idempotency key, so a slow first attempt and the retry sometimes both succeeded, and our reconciliation job then froze the order. I wrote a one-page proposal to add idempotency keys and a state check before retries, reviewed it with the payments team because it touched their API, and paired with a junior engineer to implement it so the knowledge didn't stay with me. We rolled it out behind a feature flag at 5%, then 100% over a week. Result: stuck orders dropped from about 40 a week to zero, and we've had no incidents of that type in the eight months since. I also added the scenario to our integration tests, and we now require idempotency keys for any new payment call.

Notice: "I", not "we", for your actions; the reasoning behind each step; collaboration and mentoring woven in; numbers in the result; and a lasting change. Aim for about two minutes, then let the interviewer ask follow-ups — they'll dig into the parts they need for the rubric.

#Common question families

Conflict and disagreement. "Tell me about a time you disagreed with a teammate or manager." Show that you disagreed on substance, not personality; brought data or a quick experiment; listened and might have changed your mind; and — crucially — committed fully once a decision was made, even if it wasn't yours. Never make the other person the villain.

Failure and mistakes. "Tell me about a time you failed." Choose a real failure with real consequences, not a disguised strength ("I work too hard"). Own your part without excuses, explain how you fixed it, and spend real time on what you changed afterwards. Interviewers distrust candidates who claim never to have failed.

Ambiguity and pressure. "Tell me about a time you had to deliver with unclear requirements or a tight deadline." Show how you reduced the ambiguity — questions, prototypes, cutting scope — and the trade-offs you made explicitly.

Influence without authority. "Tell me about a time you convinced others to adopt an idea." Show how you built the case — data, a design doc, a prototype — and how you brought people along rather than forcing it.

Helping others. "Tell me about a time you mentored someone or improved how the team worked." Especially important for senior roles.

Motivation. "Why do you want to join us?" and "Why are you leaving?" Be specific to the company: their product, engineering problems, scale, or culture — things you've actually researched. For leaving, focus on what you're moving towards, and never criticise your current employer.

#Mistakes that cost offers

• "We" everywhere. The interviewer can't tell what you did. Say "we" for the team's context and "I" for your actions.
• No result, or no numbers. "It went well" isn't evidence. Latency, incidents, revenue, time saved, people unblocked — estimate if you must, and say it's an estimate.
• Rambling setup. Five minutes of system context and thirty seconds of action. Keep the situation short.
• Blaming others for conflicts or failures.
• Fabricated or exaggerated stories. Follow-up questions go several levels deep ("what did your manager say then?", "what would you do differently?") and invented details collapse. Only tell true stories.
• Ignoring the question. If asked about a failure, don't tell a success story.

#Questions for them

At the end you'll be asked, "Do you have any questions?" Always have two or three ready. Good questions show that you think like an engineer on their team and help you decide whether you want the job:

• "What does a successful first six months look like in this role?"
• "How does the team decide what to build next, and how much influence do engineers have?"
• "Tell me about a recent incident and what changed afterwards."
• "How are code review, testing and deployment done day to day?"
• "What's the biggest technical challenge the team is facing this year?"

#Practice

Write a STAR answer, around 250 words, to: "Tell me about a time you disagreed with a technical decision." Then check it against this list: Is most of it Action? Is it clear what you did? Is there a measurable result? Did you commit to the final decision? Is the other person treated fairly?

Show solution

An example strong answer:

Situation: On a team of five building a promotions service, our tech lead proposed splitting it into three microservices from the start, because other teams were doing the same. Task: I thought that was premature for a team our size and that it would slow our launch, and I wanted to raise it constructively before we committed. Action: Rather than arguing in the meeting, I asked for a day to put numbers on it. I estimated the extra work — three deploy pipelines, cross-service calls that needed retries and idempotency, and integration testing — at about three extra weeks. I wrote a one-page comparison of three services versus one modular service with clear internal module boundaries that we could split later, and shared it with the lead privately first so it didn't feel like an ambush. We discussed it, and the lead raised a point I'd missed: the eligibility rules would soon need to scale independently for a big campaign. We agreed on a compromise: one service, with eligibility as a strictly separated module behind an interface, ready to extract. Result: We launched two weeks earlier than the original plan. Four months later we did extract eligibility for the campaign, and it took three days because the boundary was already clean. I learned to bring data and alternatives instead of opinions, and to share disagreements one-on-one first.

The structure works: short situation, most of the answer is specific actions with reasons, a measurable result, real respect for the other person's view, and a lesson that changed behaviour.

#Key takeaways

• Behavioral rounds score evidence of ownership, impact, collaboration, conflict handling, learning and judgment, and strongly influence your level.
• Prepare 8–10 true stories in advance and map them to the company's values.
• Use STAR, spending most of the time on your specific actions and reasoning, and finish with measurable results and lessons.
• For conflict and failure questions: disagree with data, commit once decided, own mistakes, and show what you changed.
• Say "I" for your actions, keep setup short, never blame or fabricate, and bring good questions of your own.