Describe deadline pressure, challenges, and decision changes

Approach framework - Use STAR: Situation, Task, Action, Result. - Show scope control: MoSCoW (Must, Should, Could, Won’t) and impact vs effort. - Make trade-offs explicit: what you chose, what you delayed, and why (risk, cost, latency, reliability). - Communication: audience, cadence, medium, and escalation. - Quantify results: latency, uptime, cost, conversion, tickets reduced. Sample answer 1 (covers 1–3): Hard deadline, challenging project, and stepping outside role Situation - Six weeks before a major sales event, I led a team of five engineers to ship a new delivery ETA service expected to handle 10k requests/sec peak. Dependencies included a third‑party traffic API and a mobile release train. Success criteria: 95th percentile latency ≤ 120 ms, 99.95% availability during the event, and a 20% reduction in ETA-related support contacts in pilot markets. Task - Deliver a safe, performant MVP by the fixed date, de-risk external dependencies, and ensure graceful degradation under peak load. Actions 1) Scope and trade-offs - Applied MoSCoW: - Must: ETA for top 10 metros, server-side caching, fallback to historical averages, dashboards/alerts, feature flag rollout. - Should: real-time incident rerouting, long-tail cities, mobile UI polish. - Could: animation and non-critical A/Bs. - Won’t (for MVP): per-street live telemetry and full internationalization. - Chose cache-first design with a 5-minute TTL to cap third-party calls; accepted ±5 minutes ETA error in exchange for reliability. Built a fallback path that uses historical averages if the traffic API rate-limits or times out. - Deferred city-wide dynamic traffic and complex ML model refresh to post-event iteration. 2) Technical execution - Wrote a dependency map and risk register; set explicit SLOs (P95 latency 120 ms, error rate < 0.5%). - Implemented request coalescing and circuit breakers to protect upstream APIs under surge. - Added a feature flag to roll out: 10% canary → 50% → 100%, with a kill switch tied to error budget burn rate. - Built synthetic load tests to 12k req/sec with latency histograms to validate capacity and fallbacks. 3) Communication - Established a 15-minute daily war room with eng, QA, mobile, and support; posted a red/amber/green (RAG) status with risks and owners. - Sent twice-weekly stakeholder updates (metrics, blockers, decisions) and pre-written escalation paths for rate-limit breaches. - Coordinated with support to prepare macros for known degradations and with marketing to avoid overpromising in pilot metros. 4) Responsibilities outside my role - Acted as interim PM for dependency management and external vendor coordination to keep decisions unblocked. - Wrote the initial infrastructure-as-code for dashboards/alerts and the runbook for on-call (playbooks for 5xx spike, rate limit, elevated latency). - Set up a simple experiment plan to measure contact rate changes and latency impact post-launch. Obstacles and how I handled them - Third-party API rate limits caused intermittent 429s in load test. I added token-bucket request shaping and adaptive backoff; raised a temporary quota with the vendor; validated our fallback path by forcing API timeouts in staging. - Mobile release slipped by three days. We decoupled server rollout from client with server-side toggles and provided a thin JSON response compatible with old clients. Results - Shipped two days before the deadline. P95 latency at peak: 104 ms. Availability during the event: 99.98%. - Reduced ETA-related support contacts in pilot metros by 28% over two weeks. - Zero Sev-1/Sev-2 incidents; one Sev-3 that auto-recovered via fallback. - Post-event, we added long-tail cities and dynamic traffic; the design’s modularity allowed this with minimal code churn. What I learned - Decide scope with the customer experience in mind, then protect availability with explicit fallbacks. - Invest early in observability and kill switches; they buy confidence and speed. - Stepping outside strict role boundaries to bridge PM and DevOps work can unblock the team and improve outcomes when time is fixed. Sample answer 2 (covers 4): Changing a decision based on feedback Situation - For a new event ingestion pipeline (target 8k events/sec, 3 AZ durability, 99.99% availability), I proposed self-managed Kafka to control costs and avoid vendor lock‑in. Task - Choose a solution that meets throughput, reliability, and time-to-market, without overloading SRE on operations. Actions - Gathered feedback via an RFC with SRE and FinOps. SRE flagged on-call burden (upgrades, partition rebalancing, ZooKeeper ops); FinOps shared a TCO model including people time. - Ran a one-day POC load test comparing self-managed vs a managed streaming service. Measured publish latency, consumer lag, failover behavior, and operational playbook complexity. - Documented a decision record with criteria: time-to-launch, reliability (recovery under AZ failover), latency, ops hours, and cost. Decision and incorporation - Switched to the managed service. Data showed it met throughput with P99 publish latency of 35 ms, automated failover within 10 seconds, and removed ~1–1.5 FTE of ops work. Although infra cost was ~12% higher, the earlier launch (estimated 4 weeks sooner) and reduced risk outweighed it. - Built a thin abstraction library to keep producers/consumers decoupled from vendor SDKs and documented an exit strategy. Results and learning - Launched four weeks earlier. In the first 90 days, consumer lag stayed < 250 ms at peak, and we had no paging incidents related to the stream. - Learned to evaluate total cost of ownership, not just infra line items, and to run small POCs to make feedback concrete. Keeping a decision record improved team alignment and future revisits. Checklist you can follow when answering - Situation: Fixed timeline, customer impact, and clear success metrics. - Scope: What you cut/kept and why (tie to risk/impact). - Trade-offs: Latency vs reliability vs cost; call out non-obvious decisions. - Communication: Cadence, audiences, escalation paths, artifacts (status, RFCs, runbooks). - Ownership beyond role: What you picked up, why it was necessary, and the measured impact. - Feedback-driven change: What data or risks convinced you, how you adapted, and learning. - Results: Quantify outcomes and note follow-ups you did after launch. Common pitfalls - Vague or unquantified outcomes. Include numbers and SLOs. - Listing activities without decisions. Highlight the specific trade-offs you made. - Ignoring risks. Show fallbacks, kill switches, and rollback plans. - Over-indexing on tech novelty over customer impact. Validation and guardrails to mention - Use canary rollouts with feature flags and pre-defined rollback criteria. - Monitor error budgets and tie release gates to burn rate. - Run synthetic load and failure injection tests to validate degradations and fallbacks before launch. - Keep decision logs (RFC/ADR) to capture feedback, criteria, and outcomes.