Behavioural & the STAR Method Flashcards
BEHAVIORAL › Soft Skills
- What does each letter in the STAR method stand for, and where should you spend most of your time?
- Situation (brief context), Task (your specific responsibility/goal), Action (what YOU did), Result (the measurable outcome). Spend the most time on Action and quantify the Result; keep Situation short.
- Tell me about a time you disagreed with a teammate or manager. What does the interviewer want to hear?
- A specific conflict where you argued your case with data, listened to the other side, and reached a decision. Show 'disagree and commit': once the team chose a direction, you backed it fully. Use 'I' not 'we', and end with a measurable result.
- Walk me through how you handled a critical production bug.
- Mitigate first (rollback, feature flag, hotfix) to stop user impact, communicate status to stakeholders, then find root cause (logs, Crashlytics, repro). Fix properly, add a regression test, and a prevention step (monitoring, alert, CI check) so it cannot recur silently.
- How do you approach working in a large, undocumented legacy Android codebase?
- Read before you rewrite: trace one user flow end to end, add tests around the area you'll change to create a safety net, make small incremental commits, and improve via the boy-scout rule. Avoid big-bang rewrites; modularise and refactor opportunistically with reviewer buy-in.
- Describe a decision you regret or a mistake you made. How should you answer?
- Pick a real, low-blast-radius mistake you owned. State the decision, why it was wrong, the impact, and concretely what you changed afterward. Show accountability and learning, not blame-shifting. Avoid both arrogance ('no regrets') and a catastrophic story.
- What makes a good code review comment, as both author and reviewer?
- Reviewer: be specific, kind, and focused on the code not the person; explain the 'why', distinguish blocking issues from nits (label nits), and approve when good enough. Author: keep PRs small, write clear descriptions, respond without ego, and don't merge unaddressed blocking feedback.
- Give an example of mentoring a junior engineer. What signals seniority here?
- Show you taught how to fish: paired on a problem, asked guiding questions instead of giving answers, set up a growth path, and gave feedback. Senior signal = you scaled yourself by leveling up others and improving team practices, not just shipping your own code faster.
- What does 'ownership' mean in a behavioural interview, and how do you demonstrate it?
- Taking responsibility for outcomes beyond your assigned tickets: noticing a problem and driving it to resolution, following up after launch, owning failures without blame, and improving the system (docs, tooling, on-call) so the team is better off. Bias for action plus follow-through.
- How do you stay current with Android, and why do interviewers ask?
- Name concrete, recent sources: Android Developers blog, release notes, Now in Android, KotlinConf/Google I/O talks, and hands-on side projects. They probe genuine curiosity and learning habits. Tie it to something you actually adopted, e.g. migrating to Compose or Kotlin coroutines/Flow.