Discuss complex project decisions and observability

### How to answer (what interviewers are looking for) They want evidence of (1) technical depth, (2) decision-making under constraints, (3) operational ownership, and (4) leadership/mentorship impact. Use **STAR** (Situation, Task, Actions, Results) and keep metrics concrete. --- ## 1) Recent AI project **Include** - Problem statement + why AI/ML was appropriate (or why it was constrained) - Your role: ownership boundaries, cross-team coordination - What you shipped (model, pipeline, feature, evaluation harness, monitoring) - Results: accuracy/quality + business metric **Strong details to mention** - Data sourcing/labeling, privacy constraints - Offline evaluation + online A/B testing - Failure modes (bias, drift, latency) and mitigations --- ## 2) Most complex project Complexity can be technical (distributed systems), organizational (many stakeholders), or product ambiguity. **Good structure** - What made it complex (scale, reliability, hard constraints) - How you decomposed it (milestones, interfaces, risk matrix) - What you personally drove (design doc, implementation, rollout) **Show** - Trade-offs (cost vs reliability, latency vs correctness) - Risk reduction: prototypes, load tests, staged rollouts --- ## 3) Biggest technical decision Explain it like an engineering proposal: - Context + requirements (SLOs, compliance, deadlines) - Options considered (at least 2–3) - Decision criteria (performance, reliability, operability, cost, team skill) - Final choice + why - What you would change with hindsight **Example decision themes** - Build vs buy; monolith vs microservices; streaming vs batch; SQL vs NoSQL; sync vs async; consistency model. --- ## 4) Observability: what you implemented Cover the “three pillars” plus alerting: - **Metrics**: golden signals (latency, traffic, errors, saturation). Include p95/p99 and error budget. - **Logs**: structured logs with request IDs, key dimensions, and sampling. - **Traces**: distributed tracing across services; propagation of correlation IDs. - **Dashboards/alerts**: actionable alerts tied to SLOs, not noisy symptom alerts. **Mention operational practices** - Runbooks, on-call readiness, postmortems. --- ## 5) Insight found via observability Tell a mini incident story: - Signal: what metric/trace/log showed the issue - Diagnosis: how you isolated root cause - Fix: code/config change, rollback, capacity change - Prevention: alert tuning, load test, circuit breaker, caching, query index, retry policy **Make it measurable** (e.g., “reduced p99 from 2.5s → 900ms”, “cut error rate 1.2% → 0.1%”). --- ## 6) Mentoring/coaching Show sustained impact: - Who: new hire, intern, peer, cross-team - How: pairing, code reviews, design reviews, onboarding docs, setting goals - Impact: faster ramp-up, improved quality, promotion, reduced incidents **Good framing** - Emphasize how you adapted to their level and created leverage (process/docs), not just “answered questions.” --- ### A reusable STAR template you can fill in - **S**: “We had X problem affecting Y users/metric.” - **T**: “I owned A and was responsible for B.” - **A**: “I evaluated options 1/2/3, chose 2 because…, implemented…, rolled out via…” - **R**: “Result was … (numbers), plus what I learned / follow-up actions.”