Behavioural & the STAR Method Explained
BEHAVIORAL › Soft Skills
Behavioural rounds don't test what you know, they test **how you actually work**: how you handle conflict, ship under pressure, own a production incident, or mentor a junior engineer. Interviewers aren't grading your storytelling flair, they're extracting signal about your judgement and your level.
The format they expect is **STAR**: Situation, Task, Action, Result. It's not a gimmick, it's a filter. A rambling answer forces the interviewer to dig for the parts that matter; a STAR-structured one hands them the signal directly. Every technique in this lesson is really just "how do I make my Action and Result land clearly."
Here's STAR worked through a real example:
**Situation** (one sentence of context): "Our checkout crash rate spiked to 2% right after a release." **Task** (your specific responsibility): "I was on-call and owned triaging it." **Action** (the bulk of your answer): "I pulled the top Crashlytics cluster, saw it was a null PaymentIntent on a race between two coroutines, shipped a hotfix behind a flag, and added a regression test." **Result** (quantified): "Crash-free rate recovered to 99.6% within three hours, and the regression test caught the same class of bug twice since."
Notice the weighting: Situation and Task are one line each, **Action carries the story**, and Result is short but has numbers in it.
The fastest way to weaken a story is to hide inside "we." Compare:
*Weak:* "We noticed the pipeline was flaky, so we looked into it and fixed it, and it went well." *Strong:* "I noticed our CI flake rate had crept to 30%, dug into the logs, found a shared test database causing races, and moved us to per-run containers. Flake rate dropped to 2% and review turnaround got noticeably faster."
The strong version uses **"I" for what you personally drove**, reserves "we" for genuine team context, and swaps vague praise ("went well") for a number. Even work with no headline revenue metric, like a CI cleanup, can be quantified with a credible proxy: flake rate, time saved, fewer reruns.
"Tell me about a disagreement" is really testing whether you can hold a technical position **and** work inside a team decision. The pattern interviewers want is called **disagree and commit**: state your case with evidence, genuinely listen to the counter-argument, and once the team decides, support the chosen direction fully, not grudgingly and not by quietly doing your own thing anyway.
The trap is ending the story with "and I was right all along," which reads as sour grapes even if it's true. A senior-sounding close is about the collaboration, not the vindication: you argued your position, the team chose otherwise, and you helped that choice succeed.
Sometimes disagree-and-commit doesn't apply, because the decision genuinely isn't resolving: you have data the team hasn't seen, or the call has stalled with no clear owner making it. That's when you escalate, transparently, not as an end-run around your teammates. Tell your manager or tech lead you're doing it, bring the evidence, and ask for a decision, rather than asking them to quietly overrule anyone on your behalf.
"Walk me through a production incident" has an expected order, and interviewers notice when you get it backwards. It's **mitigate, then root cause, then prevent**:
1. **Mitigate first**: rollback, kill switch, or hotfix to stop user impact, and tell stakeholders what's happening. 2. **Root cause**: only once the bleeding has stopped do you dig into logs and Crashlytics to find the actual bug. 3. **Prevent**: a fix, a regression test, and something structural (an alert, a CI check) so the same class of failure can't sneak back in silently.
Jumping straight to "I opened a debugger and found the exact line" skips the part interviewers actually want to hear: that you know reducing user pain comes before satisfying your own curiosity about the cause.
The incident story continues past prevention with one more term interviewers listen for: a **blameless post-mortem**. It follows straight from mitigate, root cause, prevent, once the immediate fire is out, the team writes up what happened without naming names or hunting for who to blame. "Blameless" doesn't mean nobody made a mistake, it means the write-up assumes whoever touched the system acted reasonably given the information and pressure they had at the time. That framing is practical, not just kind: engineers who fear blame hide near-misses and workarounds instead of surfacing them, so the same systemic gap, a missing alert, a risky manual step, quietly waits to bite again. A blameless post-mortem digs into process and system causes instead, and turns them into durable fixes.
Cross-functional stories, working with PM, design, QA, or a backend engineer, are testing whether you can influence without authority. Say a backend API forces your screen into three round trips and over-fetches fields you don't need. The weak moves are extremes: silently building a client-side workaround (backend never finds out there's a problem), or escalating to two managers on day one (skips collaboration entirely).
The strong move sits in the middle: bring the concrete use case to the backend engineer, explain the mobile constraint in plain terms, and **agree on a shaped contract together**, something like a single ProfileScreenDto with just the fields the screen needs. That's collaboration with a rationale, not a demand and not a workaround.
Agile/Scrum questions test whether you've actually worked inside sprints, not just read the Wikipedia page. A **sprint** is a fixed time-box, often one to two weeks, that ends with a demoable increment. The **daily standup** isn't a status report for a manager, it's the team syncing on progress toward the sprint goal and surfacing blockers early, so anyone stuck can get unstuck instead of sitting on it until the end of the sprint. **Story points** don't map to hours, they're a relative estimate of a ticket's complexity, effort, and risk compared to other tickets the team has already sized, which is why velocity, points completed per sprint, stays a useful planning signal even though no two engineers agree on hours. Naming these mechanics correctly, not just having "done agile," is what interviewers are actually listening for.
Code review etiquette is its own mini-topic. As a reviewer, the core skill is triage: separate **blocking** issues, correctness bugs, security holes, a race condition, from **nits**, non-blocking style or naming preferences, and label them so the author knows what actually has to change before merge versus what's optional. Explain the *why* behind a blocking comment instead of just asserting it, and stay focused on the code, not the person. As an author, keep pull requests small enough to actually review carefully, write a description that gives context up front, and respond to feedback without ego, but don't merge over an unaddressed blocking comment just because a nit got fixed. A reviewer who blocks a PR on a naming preference, or approves one with a live concurrency bug, has the triage backwards.
"Tell me about a decision you regret" is checking for growth, not perfection. Pick a real, low-blast-radius mistake you actually owned, something like shipping a feature without an analytics event, or underestimating a migration's scope, not a war story where someone else caused a catastrophe. State plainly what you'd do differently, then show what concretely changed afterward: a checklist you added, a review step you now insist on, a test you always write now. "I have no regrets" reads as either dishonest or unreflective, since everyone who's shipped real software has a story like this. Blaming a former manager or a teammate for a mistake you were part of reads as an accountability gap the interviewer will remember more than the mistake itself.
"How do you mentor" is the other half of this question pair, testing whether you can scale your impact through someone else, not just ship your own code faster. The signal interviewers want is **pairing and guiding questions** over handing over the fix: sitting with a junior engineer while they debug, asking "what have you ruled out so far" instead of pointing at the line, and explaining the reasoning behind a decision, not just the decision itself. Just fixing the junior's bugs for them clears today's ticket but leaves their actual capability unchanged, which means you'll be fixing the same class of bug again next sprint. The stronger story ends with something durable: they can now debug that category of problem without you.
One question interviewers use to probe genuine curiosity: "how do you stay current with Android?" The weak answers are extremes, claiming you already know everything, admitting you have no time to learn outside work, or rattling off trendy library names to sound informed without any depth behind them. The strong answer names real, concrete sources: the Android Developers blog and release notes, **Now in Android** (the official biweekly update video and sample app), conference talks from Google I/O or KotlinConf, and a side project where you actually try new APIs before they hit production code. Then it ties that habit to something you genuinely shipped, migrating a module to Compose, adopting coroutines and Flow over callbacks, so the answer proves the learning turned into real work, not just a reading list.