Explain your most impactful project clearly

### How to structure a strong answer (STAR + technical narrative) Use a crisp, repeatable flow: 1. **S/T (Situation/Task):** - One sentence on the business/user pain. - Define success: e.g., “reduce p99 latency from 800ms to <200ms” or “cut on-call incidents by 50%.” 2. **A (Actions):** split into **architecture + your decisions** - Start with a **level-1 diagram**: clients → APIs → core services → storage/queues → observability. - Then zoom into the “hard part” (one subsystem). - Clearly label what *you* owned: design, implementation, migration, rollout, incident response. 3. **R (Results):** - Give **numbers** (before/after) and the measurement method. - Mention secondary effects (cost, reliability, developer velocity). ### Whiteboard guidance (what interviewers look for) When drawing, explicitly annotate: - **Boundaries:** what is in/out of scope. - **Interfaces:** key APIs, events, schemas. - **Data characteristics:** QPS, payload size, retention, read/write patterns. - **Non-functionals:** SLAs/SLOs, privacy/security, failure handling. ### Typical deep-dive prompts to prepare for - “Why did you choose X over Y?” (e.g., Kafka vs. Kinesis; SQL vs. OLAP store) - “What were the failure modes and how did you mitigate them?” - “How did you roll out safely?” (feature flags, canary, backfill, dual-write) - “How did you validate impact?” (A/B test, dashboards, counterfactuals) ### Common pitfalls - **Too much context:** spending 10 minutes on background before saying what you built. - **No ownership clarity:** sounding like the team did it, not you. - **No metrics:** impact described only qualitatively. - **Diagram without data flow:** boxes but no arrows, no inputs/outputs. ### A template you can reuse (fill in quickly) - Goal: ___ - Users: ___ - Baseline pain & metric: ___ - Key design decision: ___ because ___ - Rollout plan: ___ - Result: metric moved from ___ to ___; incidents/cost changed by ___ - What you’d do differently: ___ (shows seniority and reflection)