For "a time data changed a decision," use STAR and make the decision explicit: "In a risk-policy project, the team was considering loosening a rule because we believed it was blocking too many legitimate users. My task was to quantify whether the approval gain justified the fraud risk. I built a counterfactual analysis on historical traffic, segmented by market and acquisition channel, and estimated incremental approvals, expected loss, and support impact. The data showed that most false declines were concentrated in a lower-risk segment, while another segment had much higher expected losses. Instead of a broad rule change, I recommended a limited rollout for the low-risk segment with fraud and chargeback guardrails. The decision changed from a global policy change to a targeted experiment, which improved approvals while keeping losses within threshold." This works because the analysis changed the action, not just the dashboard. For bad data quality: "I treated it like an incident. First I quantified severity: which metric, dates, tables, users, and decisions were affected. Then I reproduced the issue and isolated the source, such as a broken join, late ETL job, duplicate events, or schema change. I validated against independent sources like raw logs, ledger totals, or vendor reports. While the metric was unreliable, I labeled numbers as provisional and gave stakeholders a safe interim view. After fixing the transformation and backfilling affected dates, I added monitoring: freshness checks, volume checks, referential-integrity tests, and alerting. I also wrote a short runbook so future incidents would be faster to diagnose." The key message is ownership: you fixed the root cause and prevented recurrence. For ambiguous stakeholder requests: "I start by asking what decision the analysis will change. If we cannot name the decision, metric, and time horizon, the request is not ready for a full analysis. Then I define primary metrics, guardrails, expected impact, urgency, and effort. I sequence the smallest useful analysis first, such as a decomposition or sizing exercise, before building a complex model. I also clarify constraints from Legal, Risk, Engineering, or Product, and I set expectations on what I will and will not deliver." Useful phrasing: "If we cannot articulate the decision and the guardrails, we should not spend a week on analysis. Let us first agree on the KPI, the decision owner, and what action would follow each possible result." Common mistakes are saying "I do whatever the PM asks," overbuilding complex models when a simple decomposition would answer the decision, or hiding uncertainty. Strong answers show independent problem definition, cross-functional clarity, and risk-aware judgment.