Behavioural & the STAR Method Quiz
BEHAVIORAL › Soft Skills
In a STAR-structured answer, which component should typically receive the most detail?
- Situation, with enough detail to fully set the scene
- Task, expanded to cover every requirement in depth
- Action, emphasizing what you specifically did
- Result, lengthened into future plans and next steps
Answer: Action, emphasizing what you specifically did
Action is the core signal: it shows your specific contribution and decision-making. Situation/Task should be brief context, and Result should be concise and measurable rather than a plan.
An interviewer asks about a time you disagreed with a technical decision the team ultimately made against you. What is the strongest way to close the story?
- Explain that you were proven right later and the team clearly should have listened
- Say you disagreed but committed fully and helped the chosen approach succeed
- Describe how you quietly implemented your own preferred approach anyway
- Note that you avoided the conflict entirely by staying out of the decision
Answer: Say you disagreed but committed fully and helped the chosen approach succeed
'Disagree and commit' is the mature signal: you voice your view with evidence, then fully support the team's decision. Re-litigating, going rogue, or avoiding the discussion are all negative signals.
A high-severity crash is spiking in production. What should be your FIRST action?
- Open a debugger and pinpoint the exact root-cause line before doing anything
- Write a detailed incident post-mortem document before taking any other action
- Add new unit tests covering the affected module before doing anything else
- Mitigate user impact via rollback, flag, or hotfix and communicate status
Answer: Mitigate user impact via rollback, flag, or hotfix and communicate status
Stop the bleeding first: reduce user impact via rollback or feature flag and keep stakeholders informed. Root-cause analysis, post-mortems, and regression tests come after the immediate impact is contained.
You inherit a large, poorly documented legacy module you must change. Which approach best demonstrates good engineering judgement?
- Propose a full rewrite from scratch before you touch anything else
- Make the change quickly without tests since coverage is already low
- Refactor the whole module in one giant PR while you're already there
- Add regression tests around it, then change it in small steps
Answer: Add regression tests around it, then change it in small steps
Building a test safety net around the code you'll touch and changing incrementally is the standard for safely evolving legacy code. Big-bang rewrites and giant refactor PRs are high-risk and hard to review.
Which response to 'tell me about a decision you regret' is the strongest?
- A real mistake you owned, its impact, and the change you made after it
- I honestly can't think of any decisions I regret, so nothing to share.
- A story blaming a former manager for pushing you into a clearly bad call.
- A catastrophic production outage caused entirely by someone else on the team.
Answer: A real mistake you owned, its impact, and the change you made after it
Interviewers want accountability and learning: a genuine mistake you owned plus the concrete change it produced. Claiming no regrets, blaming others, or telling someone else's failure story all miss the point.
During a code review you spot a minor naming preference alongside a real concurrency bug. What is the best practice?
- Block the PR on both items equally so that nothing at all gets missed
- Only raise the minor naming preference to keep the review feeling friendly
- Flag the concurrency bug as blocking and mark the naming an optional nit
- Approve immediately and just fix both issues yourself after the merge
Answer: Flag the concurrency bug as blocking and mark the naming an optional nit
Good reviews separate blocking issues from non-blocking nits so the author knows what must change. Labeling severity respects the author's time while still ensuring the real bug is fixed.
In Scrum, what is the primary purpose of the daily standup?
- For the team to sync, share progress, and raise blockers
- For the manager to assign that day's tasks to each engineer
- To give detailed status reports to external stakeholders
- To estimate and re-point all remaining backlog items
Answer: For the team to sync, share progress, and raise blockers
The daily standup (daily scrum) is a short sync for the team to align on progress toward the sprint goal and raise blockers. Detailed estimation happens in refinement/planning, and it is not a top-down task-assignment meeting.
An interviewer notices your STAR stories are full of 'we did' and 'the team built'. Why does this weaken your answer?
- It sounds arrogant and can seem like you’re stealing team credit
- It breaks the STAR format’s grammar rules and makes the answer invalid
- It hides your individual impact, so they can’t assess what you did
- It makes the Situation part too long and leaves less room for detail
Answer: It hides your individual impact, so they can’t assess what you did
Behavioural rounds score your personal impact and decision-making, so overusing 'we' hides your specific actions. Use 'I' for the work you owned and reserve 'we' for genuine team context.
Your story is about cleaning up a flaky CI pipeline, but there is no headline revenue or user metric. What is the best way to deliver the Result?
- Use concrete proxy metrics, like flake rate dropping from 30% to 2%.
- Skip the Result section since the pipeline fix was internal work only.
- Say it was hard to measure, then leave the Result vague and move on.
- Claim a big revenue lift even if you have no way to attribute it here.
Answer: Use concrete proxy metrics, like flake rate dropping from 30% to 2%.
Even internal work can be quantified with credible proxy or before/after metrics like flake rate, time saved, or fewer reruns. Inventing unattributable revenue numbers is worse than an honest, concrete proxy.
In Scrum, what do story points primarily estimate?
- The exact number of hours a task will take from start to finish
- The seniority level needed to complete the task without help
- The monetary cost of the feature to the business and its users
- The relative size of a task in complexity, effort, and risk
Answer: The relative size of a task in complexity, effort, and risk
Story points are a relative measure of complexity, effort, and risk rather than precise hours, which is why teams use them to compare items and track velocity. Mapping points directly to fixed hours defeats their purpose.
A backend engineer ships an API that forces your Android screen to make several round trips and over-fetch data. What is the best collaborative first move?
- Build a client-side workaround silently so you never need to involve backend.
- Discuss the screen’s use case and agree on an API contract with rationale.
- Escalate straight to both managers now to force a change in the API design.
- Block your feature and wait until the backend team notices the issue themselves.
Answer: Discuss the screen’s use case and agree on an API contract with rationale.
Cross-functional collaboration starts with sharing the concrete use case and agreeing on an API contract together, backed by reasoning about mobile constraints. Silent workarounds and instant escalation both signal poor partnership.
A junior engineer keeps bringing you their bugs and asking you to fix them. Which response best demonstrates senior mentoring?
- Quickly fix each bug yourself so the team's sprint timeline stays on track
- Tell them to just figure it out alone since that is how you learned
- Pair with them, ask guiding questions, and model your debugging process
- Ask the manager to reassign the junior engineer to easier tickets
Answer: Pair with them, ask guiding questions, and model your debugging process
Seniority is shown by scaling yourself through others: teaching the debugging process so the junior grows more independent. Just fixing it or abandoning them solves today's bug but not the underlying capability gap.
What is the core principle of a blameless post-mortem after an incident?
- Focus on systemic and process causes and prevention, not blaming a person
- Identify exactly who made the mistake so they can be held accountable
- Keep the findings private so the team's public reputation is protected
- Skip the deeper analysis entirely if the incident was already mitigated fast
Answer: Focus on systemic and process causes and prevention, not blaming a person
Blameless post-mortems assume people acted reasonably with the information they had, so the focus is on systemic causes and durable prevention. Hunting for someone to blame discourages honest reporting and lets the real cause recur.
Asked 'how do you stay current with Android?', which answer is strongest?
- Saying you already know everything you need and rarely have to learn new things
- Listing as many trendy library and tool names as possible to sound informed
- Admitting you simply have no time to keep up outside of daily work tasks
- Naming real sources like Now in Android and tying them to what you shipped
Answer: Naming real sources like Now in Android and tying them to what you shipped
Interviewers probe genuine learning habits, so the best answer pairs real sources with something you concretely adopted and shipped. Buzzword lists, false omniscience, and 'no time' all signal weak curiosity.