### What this question is really testing Meta's behavioral rounds are scored against leadership signals, not the technical details of your story. For "disagreed with a senior engineer but had no authority to change it," the interviewer is probing four things at once: - **Influence without authority** — can you move a decision through evidence, relationships, and framing rather than title or escalation? - **Conviction balanced with humility** — do you push when the data warrants it, and do you also update when challenged? - **Data-driven judgment** — for a Data Scientist specifically, do you reduce a disagreement to a measurable question and let analysis settle it? - **Disagree-and-commit maturity** — once a decision lands (even against you), do you commit and own the outcome? Use STAR, but treat the six sub-parts in the prompt as a scoring rubric. A strong answer hits every one explicitly. Below is a reusable framework, then a concrete worked example you can adapt, then what good looks like and the common traps. --- ### A framework you can reuse Pick a *real* story where you were the analytical voice in the room, not the formal decision owner. The disagreement should be one where you turned out to be substantially right **and** where you can show you were open to being wrong. Then structure it: | STAR element | What to land | Watch for | |---|---|---| | **Situation** | Stakes, timeline, who owned the decision (someone senior, not you) | Keep it short — 2-3 sentences | | **Task** | Your specific responsibility and why you had standing to weigh in | Make clear you had *no authority*, only influence | | **Action** | Stakeholder map → 1:1s → data/experiment → decision doc → the live review | This is the longest section — most of your signal lives here; be concrete | | **Result** | The decision and **measured** outcome, including credit to others | Quantify; admit any concession you made | Two rules that keep the story credible: 1. **Address all three axes the prompt names — latency, reliability, cost — but quantify only the parts a Data Scientist would actually own.** Reason about each axis (e.g., "latency could trip notification suppression and confound my experiment"; "reliability of a synchronous fan-out compounds across dependencies"; "the precompute path reuses existing batch infra, so it's lower delivery risk"), and attach hard numbers where they're yours to produce — effect sizes, confidence intervals, sample sizes, projected metric movement, opportunity cost. For the raw infrastructure figures (actual p99 latency, measured availability, per-call compute cost), name the risk and defer the number to the engineer or SRE who can measure it. Inventing precise SLAs you'd have no way to produce (p99 latency, `0.995^4` availability) reads as fabricated in a DS interview; an interviewer who builds these systems will catch it. Reasoning about the axis and deferring the measurement is the credible move — refusing to engage the axis is not. 2. **Never invent a clean victory.** The strongest version of this story includes a real concession and the senior engineer's legitimate point. Disagreement stories where the senior person was simply wrong sound rehearsed. --- ### Worked example (adapt; do not recite verbatim) > The numbers below are illustrative placeholders. Swap in your real figures — the *structure* and the *signals* are what transfer. #### Situation We were shipping a new ranking change for a notification surface, targeting a **+0.5 pp lift in click-through rate** to hit a quarterly engagement goal, with a hard launch date tied to a campaign **six weeks out**. The senior backend engineer who owned the serving design proposed enriching features at request time by fanning out synchronously to several upstream services. I was the data scientist responsible for the model and the launch experiment — I owned *whether the change worked*, but I did **not** own the architecture or the engineer's team. #### Task My disagreement was not with the goal; it was with a risk I could measure that he had not. I believed the request-time enrichment would inflate serving latency enough to *suppress notifications* — which would confound the experiment and could erase the very CTR lift we were chasing. My job was to make that risk legible and to propose a credible alternative, with no ability to override the design. #### Action — how I built alignment (no authority) - **Mapped stakeholders and what each one cared about** before saying anything in a group setting: the senior engineer (cared about feature freshness and a clean design), the EM (cared about hitting the date), the PM (cared about the CTR target), and the experiment's integrity (my domain). Aligning the *engineer's* goal — freshness — with mine — clean measurement — was the wedge. - **Ran 1:1s first, not a public challenge.** I started with the engineer himself: "Help me understand the freshness requirement — which features actually need to be sub-minute fresh?" That conversation surfaced that **most features changed slowly**; only a small subset was genuinely fast-moving. That reframed the whole debate from "fresh vs. stale" to "how much freshness do we actually need, and where." - **Made it an empirical question.** I pulled the historical update cadence of each feature and quantified staleness sensitivity offline: simulating a few-minutes-stale feature snapshot moved offline model AUC by a negligible amount for the slow features. That turned a design opinion into a measured trade-off. - **Wrote a short decision doc**, not a Slack argument. One page: the goal, both designs, an options matrix (freshness achieved, launch risk, experiment risk, rough cost), and a rollback plan. A written artifact lets people disagree with the *idea* asynchronously instead of with *me* in a meeting. #### Action — the trade-offs I proposed, quantified for a DS to own I proposed precomputing the slow-moving features into a fast lookup on a short refresh cycle, and reserving the expensive on-request path only for the small fast-moving subset, with a graceful fallback if that path failed. I quantified it in terms I could actually defend: - **Experiment integrity:** request-time fan-out risked adding enough latency to trip the surface's existing latency-based notification suppression, which would have made the treatment arm structurally different from control — a confound that invalidates the CTR readout regardless of model quality. - **Model impact of staleness:** the offline AUC delta from a short refresh cadence was within noise for the slow features; the only features needing real-time freshness were the small fast subset, which I kept on the live path. - **Cost / effort:** the precompute path reused existing batch infrastructure, so it was *lower* delivery risk against the six-week date than standing up reliable synchronous fan-out — a point the EM cared about more than I'd expected. I deferred to the engineer on every number that was his to own (actual serving latency, capacity) and asked SRE to validate the tail-latency concern rather than asserting it myself. #### Action — handling conflict in the live design review When it came up in the review, I did four things on purpose: - **Opened by restating his design and validating the freshness goal** so it was clear I was solving *his* problem, not scoring a point. - **Anchored on shared objectives** — the launch date and a trustworthy experiment readout — so the disagreement was about how to hit *our* goals, not whose design was better. - **Let the data carry the conflict.** When he pushed back that staleness would hurt quality, I didn't argue louder; I showed the per-feature staleness sensitivity and proposed we *test it*: a small canary with guardrails (auto-rollback if latency or error rate breached threshold), so neither of us had to be right by assertion. - **Gave him a real concession.** He was correct that a couple of features I'd bucketed as "slow" were actually launch-critical; I moved those to the live path. That single concession did more to win agreement than any chart. #### Result We adopted the hybrid: precompute for slow features, live path for the fast subset, with a canary and kill-switch. We **shipped on the six-week date**. In the first two weeks the change delivered roughly the targeted CTR lift, the experiment readout was clean (latency stayed under the suppression threshold, so treatment and control were comparable), and notification-hide rates were unchanged. I credited the engineer's freshness pushback for catching the features I'd misclassified — the final design was genuinely better than either of our starting proposals. #### Part (f): if my alternative later regressed under unexpected load This is the part most candidates skip, and it's where Meta looks hardest for ownership and humility. Answer it as accountability, not as a victory lap: - **Own it first.** "If a seasonal spike doubled traffic, the precompute refresh fell behind, freshness degraded, and CTR dropped — that's a gap in *my* design. I'd own it in a blameless postmortem, not relitigate the original decision." - **Stabilize, then fix.** Immediate: trigger the kill-switch to fall back to the safe path and protect the experiment and the metric. Short-term: work with the engineer to add backpressure and scale the precompute, and tie refresh cadence to observed lag instead of a fixed schedule. Long-term: load-test at 2-3× peak with fault injection so this class of failure is caught before launch. - **Close the loop on the disagreement itself.** "The honest lesson is that my design won on the *normal-load* trade-offs the senior engineer and I both modeled, and lost on a tail scenario neither of us stress-tested. His instinct toward a simpler, more robust path had merit I'd underweighted. I'd add a 'spike/overload' row to the decision doc template so the next debate of this kind is settled with that scenario in front of us." That framing — own the regression, credit the person you originally disagreed with, and convert it into a reusable process fix — is what separates a strong L5/L6 answer from a defensive one. --- ### What a strong answer demonstrates - **You influenced through evidence and relationships**, not escalation. The 1:1-before-the-meeting, the decision doc, and "let the data carry the conflict" are the load-bearing moves. - **You quantified things a Data Scientist owns** — effect sizes, staleness sensitivity, experiment validity — and explicitly deferred to others on what wasn't yours. - **You were right *and* coachable.** The concession is not a weakness in the story; it's the strongest signal in it. - **You measured the outcome** and shared credit. - **You own failure cleanly** in part (f). ### Common pitfalls to avoid - **Fabricated precision.** Borrowed SRE numbers (`0.995^4`, p99 tails) in a DS answer invite a follow-up you can't survive. Use figures you could actually produce; state uncertain ones qualitatively. - **The hero narrative.** "I was right, they were wrong, I saved the launch" reads as low self-awareness. Build in the senior engineer's valid point and your concession. - **Going around the person.** If your influence story is really an escalation story ("I went to their manager"), it shows the opposite of what's being tested. Win the room, don't bypass it. - **Conflating opinion with data.** The whole point is that you converted a design opinion into a measurable question. If your story is "I just felt strongly," it fails the DS bar. - **Forgetting disagree-and-commit.** If the decision had gone against you, the right move is to commit visibly and help make it succeed — and to say so. Interviewers ask the inverse follow-up often. - **Skipping or hand-waving part (f).** The reflection-under-regression question is deliberate. Treat it as an owned postmortem, not a reassurance that nothing went wrong.