Behavioural & the STAR Method Explained
BEHAVIORAL › Soft Skills
Behavioural interviews aren't testing what you know, they're testing how you actually work under real conditions: how you handle conflict, ship under pressure, own a mistake, or grow a junior engineer. The interviewer isn't grading storytelling flair, they're extracting a level signal from the choices you made.
The expected format is STAR: Situation, Task, Action, Result. Situation is one sentence of context. Task is your specific responsibility inside that situation. Action is what you personally did, and it should be the bulk of your answer, because it's the only part that shows your judgement rather than just background facts. Result closes the story with a measurable outcome, not a plan for what you'd do next time.
Treat every technique in this lesson as one specific way to make your Action and Result land clearly. Underneath all of it is a single idea interviewers are listening for: ownership, whether you notice problems, drive them to resolution, and follow through past the point where it stopped being convenient.
One habit quietly weakens more STAR answers than any other: hiding inside 'we.' 'We noticed the pipeline was flaky, so we looked into it and fixed it' tells the interviewer almost nothing about you specifically, because it could describe anyone on the team, including someone who watched from the standup.
Compare that with: 'I noticed our CI flake rate had crept to 30 percent, dug into the logs, found a shared test database causing races, and moved us to per-run containers.' Same underlying story, but now the interviewer can actually score your individual contribution and decision-making, which is the entire point of the round. Use 'I' for the work you specifically drove. Reserve 'we' for genuine team context, like a decision the group made together or credit you're deliberately sharing. This isn't about sounding boastful, it's about giving the interviewer the information they came for.
Not every story has a headline number like revenue or conversion rate sitting nearby. A CI pipeline cleanup, a refactor, or an internal tooling fix rarely shows up on a dashboard executives look at. That doesn't mean the Result should go soft.
Every piece of engineering work has some measurable proxy: flake rate, build time, time-to-first-review, crash-free rate, on-call pages per week, lines of duplicated code removed. Find the number closest to the actual problem you solved, capture it before and after, and use that. Compare 'it went well' with 'flake rate dropped from 30 percent to 2 percent and review turnaround got noticeably faster.' The second version is honest, specific, and gives the interviewer something concrete to remember your story by. What you should never do is reach for an unrelated, unattributable number, like claiming a revenue lift you have no way to trace back to your change. A vague Result is forgettable. A fabricated one is a credibility risk.
'Tell me about a disagreement' is testing something specific: can you hold a technical position and still work inside a team decision that goes against you. The pattern interviewers are listening for has a name, 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 building your own preferred version anyway.
The classic trap is ending the story with 'and I was right all along.' Even when it's true, that close reads as sour grapes, and it signals to the interviewer that you're still relitigating a decision the team already made. The senior-sounding close is about the collaboration, not the vindication: you argued your position, the team chose otherwise, and you helped that choice succeed.
Disagree and commit doesn't apply everywhere. If you have data the team genuinely hasn't seen, or a decision has stalled with no clear owner, that's when you escalate, transparently, telling your manager or tech lead you're doing it rather than asking them to quietly overrule a teammate behind the scenes.
'Walk me through a production incident' has an order interviewers expect, and they notice immediately when you get it backwards: mitigate, then root cause, then prevent.
Mitigate first means stopping user impact right now, a rollback, a feature flag kill switch, or a scoped hotfix, and telling stakeholders what's happening while you do it. Only once the bleeding has stopped do you move to root cause: pulling logs, Crashlytics clusters, and a repro case to find the actual bug. Prevent comes last: a proper fix, a regression test, and something structural, an alert or a CI check, so the same class of failure can't sneak back in silently.
The classic mistake here is opening with 'I opened a debugger and pinpointed the exact line.' It sounds thorough, but it skips the part interviewers actually want to hear, that you know reducing pain for whoever hit the crash comes before satisfying your own curiosity about the cause. A kill switch like a remote config flag is often the fastest mitigation available, because it needs no release.
The incident story has one more beat past prevention that interviewers specifically listen for: the blameless post-mortem. Once the 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, and it focuses on process and system causes instead, a missing alert, a risky manual deploy step, an undocumented assumption, and turns those into durable fixes.
This framing is practical, not just kind. Engineers who fear being blamed hide near-misses and workarounds instead of surfacing them, so the same systemic gap quietly waits to bite again. A team that hunts for a name to attach to an incident gets less honest reporting over time, not more accountability.
Inheriting a large, undocumented legacy module is its own behavioural question, because how you approach it says a lot about engineering judgement under uncertainty. The instinct to propose a full rewrite is usually the wrong one: rewrites take longer than estimated, drop undocumented edge cases the old code quietly handled, and are hard for anyone to review as one giant diff.
The safer, senior pattern is: read before you touch, trace one user flow end to end, add tests around the specific area you're about to change to build a safety net, then change it in small, reviewable steps. A characterisation test doesn't assert what the code should do, it locks in what the code actually does right now, so you find out immediately if a change accidentally shifts behaviour nobody asked for.
Big-bang rewrites and giant refactor PRs done 'while you're already in there' are both high-risk moves that this question is specifically probing for. The strongest answer shows restraint: small steps, a growing safety net, and the boy-scout rule of leaving each corner slightly better than you found it.
Code review etiquette shows up as its own behavioural question because triage is the actual skill being tested, not niceness. As a reviewer, separate blocking issues, correctness bugs, security holes, a race condition, from nits, non-blocking style or naming preferences, and label which is which so the author knows exactly what has to change before merge versus what's optional.
Explain the why behind a blocking comment instead of just asserting it, and keep the conversation 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 never merge over an unaddressed blocking comment just because an unrelated nit got fixed.
Getting the triage backwards in either direction is the tell interviewers are listening for: blocking a PR on a naming preference wastes everyone's time, and waving through a PR with a live concurrency bug because raising it felt awkward is worse.
Cross-functional stories, working with a PM, designer, QA, or a backend engineer, are testing whether you can influence a decision without having authority over the person making it. A common shape: a backend engineer ships an API that forces your screen into three round trips and pulls back fields you don't need.
The weak moves sit at the extremes. Silently building a client-side workaround means backend never learns there's a problem, so it recurs for the next screen. Escalating straight to two managers on day one skips collaboration entirely and burns trust you'll want later.
The strong move sits in the middle: bring the concrete use case to the backend engineer, explain the mobile constraint in plain terms, network round trips cost latency and battery, over-fetching costs bandwidth, and agree on a shaped contract together, something like a single screen-specific DTO with only the fields that screen actually needs. That's influence backed by a rationale both sides can see, not a demand and not a silent patch.
Agile and Scrum questions are checking whether you've actually worked inside sprints, not just read a glossary. A sprint is a fixed time-box, often one to two weeks, that ends with a demoable increment of working software.
The daily standup is the piece people most often describe wrong. It isn't a status report delivered up to a manager, and it isn't the moment tasks get assigned for the day. It's the engineers syncing with each other on progress toward the shared sprint goal and surfacing blockers early, so someone stuck on a problem can get unstuck instead of sitting on it silently until the sprint review. Naming what a standup is actually for, in your own words, signals real experience working this way far more than saying you 'do agile.'
Story points are the other Scrum mechanic interviewers probe, mostly because candidates who haven't actually estimated in a team get this one wrong. A story point isn't a disguised hour. It's a relative measure of a ticket's complexity, effort, and risk compared to other tickets the team has already sized together.
That relativity is the entire point: two engineers will never agree on exact hours for a task, but a team can usually agree that fixing a null-pointer crash is smaller than migrating an entire module to Compose. Because the unit is relative rather than absolute, velocity, points completed per sprint, stays a useful planning signal over time even though no two people would estimate the same task in hours the same way. Mapping points directly back to fixed hours defeats the reason teams use them in the first place.
'Tell me about a decision you regret' is checking for growth, not perfection. Pick a real, low-blast-radius mistake you actually owned, shipping a feature without an analytics event, underestimating a migration's scope, not a war story where someone else caused a catastrophic outage and you happened to be nearby.
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. That second half, the concrete change, is what separates this from just confessing.
'I honestly can't think of any' reads as either dishonest or unreflective, since everyone who has shipped real software has a story like this. Blaming a former manager or a teammate for a call you were part of reads as an accountability gap the interviewer will remember longer than the mistake itself.
'How do you mentor' tests whether you can scale your impact through someone else, not just ship your own code faster. When a junior engineer keeps bringing you their bugs to fix, the fastest option, just fixing it yourself, 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 signal interviewers want is pairing and guiding questions over handing over the answer: sitting with them while they debug, asking 'what have you ruled out so far' instead of pointing at the line, and explaining the reasoning behind a fix, not just the fix itself. The strongest version of this story ends with something durable, they can now debug that category of problem without you, which is the actual measure of whether mentoring worked.
'How do you stay current with Android?' is a curiosity probe, and the weak answers all sit at extremes. Claiming you already know everything you need reads as complacent in a platform that ships major changes yearly. Admitting you have no time to learn outside daily tasks reads as passive. Rattling off a list of trendy library names without depth behind any of them reads as buzzword-matching rather than actual learning.
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, talks from Google I/O or KotlinConf, and a side project where you 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 instead of just a reading list.