Behavioral & HR interview questions

STAR structure: Situation: Briefly describe the context — what decision was being made, what was the disagreement. Task: What was your role? Why did you care about this? Action: Explain what you did — did you present data? Propose a spike/experiment? Have a 1:1 with the tech lead? Accept the team decision after being heard? Result: What happened? Did the team change direction or stick with their decision? What did you learn? Key signals interviewers look for: - You advocated with data/reasoning, not emotion - You raised concerns at the right time (design phase, not after shipping) - You accepted the decision gracefully once the team decided - You can articulate what you learned from the disagreement

Good structure: 1. What was the project? (1-2 sentences, audience-appropriate context) 2. What was the specific problem or challenge? 3. What did YOU do? (specific actions, decisions, code written) 4. What was the outcome? (metrics: latency improved, revenue impact, user growth) 5. What would you do differently? Key pitfalls to avoid: - Saying "we" for everything — interviewers want YOUR contribution - Choosing something too old or irrelevant to the role - Not having metrics or a clear outcome - Picking something too simple for your experience level Tip: Have 2-3 projects ready across different domains (technical depth, cross-team collaboration, ambiguous problem).

STAR approach: Situation: describe a real project with unclear scope and deadline pressure. Action framework to demonstrate: 1. Clarify: immediately schedule a meeting to understand what "done" looks like. Get the 3 most important requirements vs. nice-to-haves. 2. Scope cut: identify what can be deferred without breaking the core delivery. 3. Communicate early: flag risks early (not the night before). "We can deliver X by Friday or X+Y by next Wednesday — which is more important?" 4. Deliver and document: ship the MVP, document what's deferred and why. What NOT to say: "I just worked overtime." Shows lack of judgment. What interviewers want: you can prioritize, communicate trade-offs, and deliver under pressure without burning yourself or the team out.

STAR structure: Situation: describe a real failure — a project that missed deadline, a production bug you caused, a technical decision you regret. Task: what were you responsible for? Why was this a significant failure? Action: what happened? What mistakes were made? What did you do when you realised? Result: concrete outcome + what you changed as a result. What interviewers look for: - Self-awareness: do you understand what went wrong, including your own role? - Learning: did you change behaviour, process, or approach afterward? - Recovery: did you handle it responsibly — inform stakeholders, not hide it? Red flags: - "I can't think of a failure" — either dishonest or no self-reflection - Blaming the team entirely without owning your part - No learning or behaviour change Tip: have 2 real failures ready — one technical, one interpersonal.

Good structure: 1. Context: what was the technology and why did you need it quickly? 2. Your approach: how did you prioritise? (official docs, hands-on projects, community, mentor) 3. What you built or shipped: shows you went beyond just reading 4. Timeline and outcome: how fast did you reach productivity? Strong signals: - You have a repeatable learning system (build a small project first, not just tutorials) - You knew what you didn't know and asked for help strategically - You can describe specific resources that helped - You kept notes/documentation for the team What to avoid: - "I'm a fast learner" without any evidence - Exaggerating the timeline

STAR approach: Action framework to demonstrate: 1. Triage by impact and urgency: production outage > feature > tech debt. 2. Communicate early: "I can finish A by Friday or B+C by next week — which matters more?" Don't silently drop things. 3. Time-box: fixed slots per task, daily review to reprioritise. 4. Say no constructively: "I can do this, but X will slip. Is that the right trade-off?" 5. Document: keep a visible task list shared with stakeholders. What NOT to say: "I just work 12-hour days until everything is done." Interviewers want: prioritisation skills, proactive communication, ability to push back with evidence.

STAR structure: Situation: describe the incident — severity, user impact, timeline. Action — walk through the response: 1. Detect: how was it found? Alerts, user reports? 2. Triage: what was the blast radius? 3. Mitigate: rollback, feature flag off, hotfix 4. Communicate: who did you notify? 5. Root cause: what actually caused it? 6. Postmortem: what did you change to prevent recurrence? Strong signals: - Structured incident response approach - Prioritise mitigation before root cause (stop bleeding first) - Blameless postmortem — focused on system fixes, not people - Concrete improvement shipped afterward (better monitoring, tests, runbook)

Good structure: 1. What was the problem? (slow deployment, manual testing, repetitive bug pattern) 2. How did you identify it? (data, metrics, pain point that kept recurring) 3. What did you do? (proposed, designed, built, drove adoption) 4. What was the measurable result? Quantify: "reduced deployment time from 45 minutes to 8 minutes," "eliminated 90% of manual regression steps." What makes this question interesting for interviewers: do you proactively see waste and fix it? Or do you only execute assigned work?

Structure: 1. Context: who was the junior? What was their gap? 2. Your approach: how did you mentor? (regular 1:1s, code reviews, pairing, structured learning plan) 3. Challenges: did they struggle? How did you adapt? 4. Outcome: what did they accomplish? How did they grow? Strong signals: - Adapted your style to their learning needs - Gave constructive feedback in code reviews — specific, not vague - Helped them build confidence for tasks, then stepped back - Measured their growth (they shipped independently, led a feature)

What works: - Growth opportunity: "I've learned a lot at my current company. I'm looking for a role where I can take ownership of larger systems." - Technical scope: "The stack at my current company is limiting. I want to work with modern cloud-native technologies." - Culture/mission fit: "This company's mission resonates strongly with me." - Genuine life change: relocation, role restructuring — factual and acceptable. What doesn't work: - "My manager is terrible" — even if true, never say it - Vague negativity: "I just need a change" - Badmouthing products, codebase, or colleagues Script: "I've spent N years at [Company] and built [X]. I'm now looking for [specific thing this role offers]."

Strong answer components: 1. Specific sources: newsletters (TLDR, ByteByteGo, The Pragmatic Engineer), podcasts, GitHub trending, conference talks. 2. Applied learning: "When I read about a pattern, I build a small proof-of-concept before using it in production." 3. Community: open source contributions, writing blog posts, attending meetups. 4. Deliberate practice: personal projects to explore new stacks. What to avoid: - "I read Medium articles" — too vague - "I follow Twitter" — passive consumption without application - No specific example of something you learned recently Close with a specific recent thing: "Right now I'm exploring [X] because [reason] — I've built a small [project] to test it."

STAR structure: Situation: a team was about to adopt a technology/approach you believed was wrong. Task: you weren't the tech lead or manager. Action: 1. Gathered data — benchmarks, case studies, spike results (not just "I think") 2. Identified allies — built a coalition 3. Presented at the right time and forum 4. Framed it as trade-offs, not "I'm right, you're wrong" 5. Accepted the outcome — committed to the team decision Key signals: you used evidence, not politics; you respected the process.