Describe project impact and feedback
Company: DoorDash
Role: Software Engineer
Category: Behavioral & Leadership
Difficulty: medium
Interview Round: Onsite
Describe a recent project you led or significantly contributed to: the problem, your role, key design decisions, and measurable outcomes. What specific feedback did you receive from your manager and product stakeholders, and how did you incorporate it? In retrospect, what would you change to improve impact or execution?
Quick Answer: This question evaluates leadership, ownership, communication, stakeholder management, and the ability to articulate technical trade-offs and measurable outcomes in a software engineering context, and is commonly asked because interviewers use it to judge real-world decision-making, accountability, and cross-functional impact.
Solution
Below is a step-by-step approach, a fill-in template, and a fully worked example tailored to a software engineer in a consumer marketplace/logistics context.
## How to Structure Your Answer (STAR-FR)
Use STAR-FR: Situation, Task, Actions, Results, Feedback, Retrospective.
1) Situation: One sentence with business context and pain.
2) Task: Your ownership, goals, and constraints (SLOs, timelines, risk).
3) Actions: Key design decisions, trade-offs, cross-functional collaboration, execution.
4) Results: Quantified outcomes vs. baseline (conversion, latency, errors, revenue, cost) and timelines.
5) Feedback: What your manager/PM said, what changed as a result.
6) Retrospective: What you’d do differently and why.
Tip: Keep it 2–3 minutes; emphasize your decisions and impact. Avoid a feature tour; focus on problems, trade-offs, and outcomes.
## Quick Checklist Before You Answer
- Choose a project with measurable impact and clear ownership (6–12 weeks is ideal).
- Have pre/post metrics ready (e.g., p95 latency, error rate, conversion, revenue, cost).
- Name 2–3 high-leverage technical decisions and the trade-offs.
- Prepare one concrete piece of stakeholder feedback you incorporated.
- Have a crisp retrospective improvement.
## Fill‑In Template
- Situation: "Our [product area] had [problem], causing [impact] for [users/business]."
- Task: "As [role], I owned [scope] with goals of [target metrics] under [constraints]."
- Actions:
- "Chose [design/approach 1] over [alternative] to optimize [X]; trade-off was [Y]."
- "Implemented [design/approach 2] to address [bottleneck]; validated via [experiment/benchmark]."
- "Partnered with [teams] to [dependency/risk mitigation]. Rolled out via [canary/feature flags]."
- Results: "In [time], [metric A] improved from [baseline] to [result] (Δ = [absolute/relative]); [metric B] changed by [Δ]."
- Feedback: "Manager/PM feedback: [quote/summary]. I incorporated it by [change], resulting in [effect]."
- Retrospective: "Next time I’d [improvement] because [reason/impact]."
## Worked Example Answer (Software Engineer)
- Situation: Our checkout service had high p95 latency (~950 ms) during peak, leading to timeouts and a measurable drop in order conversion.
- Task: As the lead engineer for checkout performance, I owned reducing p95 latency below 600 ms and stabilizing error rates under 0.5%, without increasing infra cost by more than 5% and with zero downtime.
- Actions:
- Re-architected price and fee calculation to be async with an edge cache. I chose a write-through cache with 5‑minute TTL for stable fee components and a short 30‑second TTL for volatile surge multipliers; trade-off: slightly stale prices in rare cases, mitigated with a correctness check at payment auth.
- Added circuit breakers and graceful fallbacks for non-critical calls (e.g., promotions), ensuring checkout remained functional even if downstream services degraded.
- Indexed hot DB queries and introduced a read replica for high-QPS reads. Validated improvements with flame graphs and load tests (baseline vs. optimized).
- Rolled out via feature flags with a 5%→25%→50%→100% canary, SLO dashboards, and automatic rollback on p95 > 800 ms or error rate > 0.7%.
- Partnered with Payments and Promotions to align on idempotency keys and to propagate fallback reasons in observability to aid incident response.
- Results:
- p95 latency: 950 ms → 610 ms (−36%) in three weeks; p99: 1.9 s → 1.1 s (−42%).
- Checkout error rate: 1.2% → 0.4% (−67%).
- Order conversion: +0.6 percentage points in A/B (95% CI: +0.3 to +0.9 pp). Uplift persisted through two major promos.
- Infra cost: −8% due to cache hit rate ~82% and reduced DB load. No customer-facing incidents during rollout.
- Feedback and Incorporation:
- Manager: Asked for clearer ownership of SLOs and on-call readiness. I added dashboards with burn-rate alerts and a runbook; we cut mean time to detect from ~8 to ~3 minutes in subsequent weeks.
- Product: Wanted stronger guardrails during the promo week. I introduced dynamic kill switches per cohort and tightened rollback thresholds; we avoided impact during a partner outage.
- Retrospective:
- I would engage the Payments team two weeks earlier to align on idempotency and authorization retries; it would have eliminated a late-stage bug and saved ~3 days.
- I’d invest in chaos testing for downstream timeouts earlier; we discovered an edge case only after 50% rollout.
- I over-optimized p50 initially; focusing earlier on p95/p99 would have accelerated impact.
## Why This Works
- Clear problem framing tied to business impact
- Specific technical decisions with trade-offs
- Quantified, validated results (A/B tests, SLOs)
- Shows leadership: cross-team alignment, safe rollout, observability
- Reflective mindset with concrete improvements
## Common Pitfalls to Avoid
- Vague outcomes ("made faster") without numbers
- Overuse of "we" with no clarity on your ownership
- Laundry list of tasks without decisions/trade-offs
- No rollback/guardrails; no validation method
## Final Tips
- Keep a crisp narrative spine: Problem → Decisions → Proof → Learning.
- Bring a second backup project in case the interviewer probes for another example.
- If you cannot disclose sensitive metrics, provide ranges and relative changes (e.g., "~30–40% reduction").