Describe projects, conflicts, and tough stakeholders

## What the interviewer is evaluating They’re testing whether you can: - Communicate technical work clearly to a non-deep specialist. - Demonstrate ownership, prioritization, and tradeoff thinking. - Handle ambiguity and cross-team dependencies maturely. - Resolve conflict without blame; operate with empathy and professionalism. - Show impact beyond “I wrote code” (reliability, cost, latency, developer productivity, revenue, risk reduction). --- ## A strong structure for every answer: STAR + “So what?” Use **STAR** and add a crisp **Impact** line. - **S (Situation):** 1–2 sentences of context. - **T (Task):** what you owned / what success meant. - **A (Action):** 3–6 bullets; focus on your decisions, not the team’s. - **R (Result):** measurable outcome. - **So what:** why it mattered to customers/business/engineering. Keep each story to ~2–4 minutes, then invite questions. --- ## 1) “Tell me about your current project” (how to answer) ### Recommended outline 1. **One-liner:** “I’m building X for Y users to achieve Z.” 2. **Scale & constraints:** traffic, data size, latency/SLA, compliance, timeline, team size. 3. **Your ownership:** design, implementation, oncall, migration, stakeholder management. 4. **Key tradeoffs:** correctness vs latency, build vs buy, iteration plan. 5. **Impact metrics:** adoption, error rate, p95 latency, infra cost, cycle time. ### If your project scope feels “small” Reframe “scope” into: - **Depth:** complexity, reliability, correctness, security, operational rigor. - **End-to-end ownership:** requirements → design → launch → monitoring → iteration. - **Leverage:** tooling that saves many engineers time, reduces incidents, prevents regressions. Example phrasing: - “While the surface area was limited, the constraints were strict (SLA, risk, migration safety). I owned the rollout plan and reduced incidents by X%.” --- ## 2) “Describe a technical challenge” (pick a story that shows method) ### Pick one with a clear arc Good categories: - Production incident with mitigation + prevention. - Performance bottleneck (latency/cost) with profiling. - Data correctness bug with root-cause analysis. - Migration/rollout challenge with safe deploy strategy. ### What to emphasize (the interviewer’s checklist) - **How you narrowed scope:** hypotheses, instrumentation, reproductions. - **How you made it safe:** feature flags, canaries, rollback, tests. - **How you prevented recurrence:** monitors, runbooks, postmortem actions. A compact action sequence: 1. Detect/confirm impact (dashboards/logs/traces). 2. Contain (rollback, disable feature, rate limit). 3. Diagnose (bisect, diff, traces). 4. Fix + validate (unit/integration/load tests). 5. Prevent (alerts, SLOs, guardrails). --- ## 3) Cross-team conflict: “Infra caused a bug” + reverse perspective ### First: as the downstream/service team **Goal:** resolve quickly while preserving relationships. **High-signal approach:** 1. **Assume good intent; focus on facts.** - “We’re seeing increased 5xx and p95 latency after time T.” 2. **Bring evidence.** - timestamps, request IDs, logs, traces, before/after metrics, rollback results. 3. **Propose a minimal reproduction or isolation plan.** - “We can flip config A, test in staging, or route 1% traffic to compare.” 4. **Use the right channels.** - incident bridge if customer impact; otherwise a ticket + paging policy. 5. **Align on ownership and next update time.** - “I’ll validate from my side; can you check recent deploys/config changes? Let’s sync in 30 minutes.” 6. **Close the loop.** - Document root cause, add runbook/monitoring, and capture learnings. **Pitfalls to avoid:** blame language (“your team broke it”), vague reports (“it’s slow”), or escalating too early without data. ### Then: as the infra/platform team (reverse empathy) Show you understand their constraints: - Many tenants; need to manage risk, blast radius, and reproducibility. - Changes must be rolled out safely; may require maintenance windows. Strong answer components: 1. **Acknowledge and triage severity** (S1 vs S2). 2. **Check recent changes** (deploys/config/feature flags) and correlate with metrics. 3. **Provide workarounds** (rollback, pin version, disable optimization, increase quotas). 4. **Communicate clearly** (ETAs, next update time, who owns what). 5. **After action:** add guardrails, staged rollouts, tenant-specific alerts. --- ## 4) “Tell me about a difficult person” (answer without sounding toxic) ### What they want Can you influence without authority, set boundaries, and still deliver. ### A safe template - **Describe behavior, not personality.** - “They frequently changed requirements late” vs “they were impossible.” - **Show your response:** clarify expectations, written agreements, regular check-ins. - **Use empathy:** “They were under deadline pressure / lacked context.” - **Outcome:** improved collaboration + delivered result. ### Techniques to mention (pick 1–2) - **Expectation setting:** RACI, decision logs, written requirements. - **De-escalation:** private conversation, active listening, “seek to understand.” - **Alignment:** restate goals, propose options with tradeoffs. - **Boundary setting:** “To hit date D, we need freeze by date C.” - **Escalation (only when needed):** with facts, proposed solutions, and minimal drama. --- ## Quick preparation checklist (15–30 minutes) Prepare 4 stories: 1. Most impactful project. 2. Hard technical debugging/incident. 3. Cross-team dependency/conflict. 4. Interpersonal challenge. For each, write: - 1-sentence summary - 3 action bullets - 1 metric outcome - 1 lesson learned This keeps answers concise, confident, and consistent under time pressure.