Netflix Staff Data Analyst Interview Preparation Guide

Direct answer. A sensitivity analysis quantifies how strong an unmeasured confounder would need to be, in terms of its relationship to both treatment and outcome, before it could fully explain away your observed effect. Two standard tools are Rosenbaum bounds, which ask how much an unmeasured factor could distort the odds of treatment assignment before your conclusion (the p-value or effect direction) becomes unreliable, and the E-value, a more recent and more directly interpretable measure of the minimum strength of association, on the risk-ratio scale, that an unmeasured confounder would need with BOTH treatment and outcome to fully explain away the estimate.

Structured elaboration. The E-value for an observed risk ratio $RR$ (for $RR \geq 1$) is:

This gives the minimum risk ratio an unmeasured confounder would need to have with BOTH the treatment and the outcome, on this same multiplicative scale, to fully explain away the observed association. A larger E-value means a stronger, harder-to-dismiss result; an E-value close to 1 means even a weak unmeasured confounder could explain the whole effect away.

Worked example. Suppose an observational estimate finds a risk ratio of $RR = 1.5$ for a retention-boosting feature. Computing the E-value:

This means an unmeasured confounder would need to be associated with BOTH feature adoption and retention by a risk ratio of at least about 2.37 (each) to fully explain away the observed 1.5 effect. A plain-language interpretation for a non-technical stakeholder: "for this result to be spurious, there would need to be some unmeasured factor that makes users roughly two and a half times more likely to both adopt the feature and retain, purely by coincidence with the true effect being zero. Given the confounders we've already controlled for, that's a high bar, but not an impossible one, which is why we're still recommending a confirmatory experiment before scaling investment."

Trade-offs and pitfalls. A sensitivity analysis doesn't prove the result is unconfounded, it quantifies how much confounding would be needed to overturn it, which is a meaningfully different and more honest claim; the biggest pitfall is presenting a comfortably large E-value as proof of causality, when a genuinely strong unmeasured confounder (a marketing campaign that happened to target both feature-adopters and high-retention users) could still plausibly exceed even a moderately large threshold.

Quick answer

The population distribution describes how a variable is spread across every individual unit in the population; the sampling distribution of the sample mean describes how the average of a sample varies across repeated samples drawn from that population. They can look completely different: the population can be skewed or even binary, while the sampling distribution of the mean tends toward a normal shape as sample size grows, regardless of the population's shape. Inference (confidence intervals, p-values, hypothesis tests) is built entirely on the sampling distribution, which is why this distinction matters: you're never directly observing the sampling distribution, only reasoning about it theoretically.

Definitions and contrast

Population distribution: the distribution of the variable itself across every unit, e.g. every user's individual conversion outcome (0 or 1). It has population mean $\mu$ and standard deviation $\sigma$, and can be any shape.

Sampling distribution of the sample mean $\bar{X}$: the distribution you'd get if you repeatedly drew samples of size $n$ from the population and computed the mean of each one. Its properties:

By the Central Limit Theorem, this sampling distribution approaches a normal shape as $n$ grows, even when the underlying population is not normal at all (e.g. Bernoulli conversion outcomes).

Why the distinction is critical for inference

Confidence intervals and p-values are statements about how much a statistic (like a sample mean or a difference in proportions) would vary across hypothetical repeated samples, which is exactly what the sampling distribution characterizes. If you mistakenly reason from the population's raw shape instead, for instance, treating a skewed population as evidence that your estimate is unreliable, you'd be ignoring the fact that averaging shrinks variability and normalizes shape, both captured by the sampling distribution, not the population distribution.

Worked A/B testing example

Two variants with true conversion rates $p_A = 0.10$ and $p_B = 0.12$, each population distribution is Bernoulli, sharply non-normal (only two possible values, 0 or 1). Running the test with $n = 2000$ users per arm:

import numpy as np
from scipy import stats

pA, pB = 0.10, 0.12
n = 2000
se = np.sqrt(pA * (1 - pA) / n + pB * (1 - pB) / n)
diff = pB - pA
z = diff / se
p_val = 2 * (1 - stats.norm.cdf(abs(z)))
print(f"SE={se:.5f}, z={z:.3f}, two-sided p={p_val:.4f}")
# SE=0.00989, z=2.022, two-sided p=0.0431

The population distribution of an individual user's conversion outcome is Bernoulli, nowhere close to normal. But the sampling distribution of the difference in conversion rates, $\bar{X}_B - \bar{X}_A$, across repeated 2000-user samples per arm, is approximately normal by the CLT, with standard error $\approx 0.0099$. That's what lets us compute a z-score of about 2.02 and a two-sided p-value of about 0.043, treating $\bar{X}_B - \bar{X}_A$ as approximately normally distributed, even though no individual user's outcome is anything close to normal.

Trade-offs and pitfalls

• The CLT needs "enough" $n$, and "enough" depends on how non-normal the population is. A heavily skewed population (e.g. purchase amounts with a long right tail) needs a larger $n$ before the sampling distribution of the mean is well-approximated by normal than a symmetric population does.
• Standard error shrinks with $\sqrt{n}$, not $n$. Quadrupling the sample size only halves the standard error; this nonlinear relationship is a frequent source of underestimating how much data is needed to meaningfully tighten a confidence interval.
• Conflating "the data looks non-normal" with "my inference is invalid" is a common and incorrect instinct. What needs to be approximately normal for a mean-based test is the sampling distribution of the statistic, not the raw population.

Hypothesis: reducing booking fees for subscribers increases trip frequency and revenue per user by raising retention and trip volume. Design: randomized A/B test where eligible frequent riders are split into control (no change) and treatment (subscription feature: reduced booking fee). Metrics: primary — trips per user/week; secondary — net revenue per user, conversion to paid subscription, churn. Duration: run for 8–12 weeks to capture behavior and seasonality. Sample size: power to detect 5% lift with alpha=0.05 requires ~10k users/arm (estimate depends on baseline trip variance). Guardrails: cap promotional exposure, monitor cannibalization (existing discounts), ensure no negative impact on driver earnings; run stratified randomization by city and rider segment. Analysis: intent-to-treat, uplift by cohort, revenue-per-user decomposition (fare, fees, trips). Stop criteria: statistically significant negative margin impact or adverse operational signals (driver supply issues).

Direct answer
Communicating forecast uncertainty to executives who must act on it (inventory, staffing decisions) means translating a statistical interval into a decision-oriented visual, a short plain-language narrative, and explicit risk thresholds tied to concrete actions - not handing over a probability distribution and expecting the audience to translate it themselves.

Structured elaboration

• Visualization types: a fan chart (point forecast with shaded, widening interval bands) communicates growing uncertainty with horizon at a glance; a simple range ("between X and Y, most likely around Z") often lands better in a text summary than any chart at all for a purely numeric decision; avoid overlaying too many scenario lines at once, which tends to overwhelm rather than clarify.
• Concise narrative elements: lead with the single most decision-relevant number (the range or the risk threshold status), not the model's mechanics; name the one or two biggest drivers of the uncertainty in plain language ("wider because we're extrapolating past our most recent clean data" or "wider because this coincides with an unproven new product launch"), since a bare number with no explanation of why it's uncertain reads as arbitrary.
• Risk thresholds: translate the interval into a concrete operational risk statement - "there's roughly a 1-in-10 chance demand exceeds X, which is above our current safety-stock coverage" is directly actionable in a way that "the P90 is X" is not to most executive audiences.
• Simple decision rules that map probabilistic outputs to clear operational actions: pre-agree, before the forecast is even needed, what action gets triggered by which outcome - e.g. "if the lower bound of the interval falls below the minimum staffing threshold, escalate for a contingency staffing review" - so the moment of decision doesn't require re-deriving probabilistic reasoning under time pressure.
• Scoping the ask before producing the forecast: a related discipline worth naming up front - before building any of this, clarify with the requesting stakeholder exactly what decision the forecast will drive (which determines the right horizon, granularity, and confidence-level framing) and what specific data/features are available, rather than producing a generic forecast and hoping it fits whatever decision comes later.

Worked example
For inventory/staffing decisions specifically, present three things together: the point forecast, an explicit range (e.g. "80% chance actual demand falls between 8,200 and 11,400 units"), and a one-line translation into the operational decision ("current safety stock covers up to 10,500 units - there's a real, non-trivial chance demand exceeds that, so we recommend increasing the buffer by roughly 10%") - this closes the loop from statistical output to a concrete, arguable recommendation rather than leaving that translation to the reader.

Trade-offs & pitfalls
The most common failure in this space is presenting a wide, honest interval with NO accompanying guidance on what to actually do about the width, which either gets ignored (executives revert to the point estimate) or causes decision paralysis; conversely, presenting a false-precision point estimate with no uncertainty at all removes the information needed to make a risk-aware call. The goal is neither raw statistical output nor false confidence, but a translated, action-oriented version of the genuine uncertainty.

Direct answer

For heavy-tailed data, reach for the trimmed mean (the mean after dropping a fixed percentage from each tail), the winsorized mean (capping extreme values at a percentile rather than dropping them), and the median absolute deviation, or MAD (a robust measure of spread built from the median rather than the mean). Each protects against exactly what the plain mean and standard deviation are vulnerable to: a small number of extreme values dominating the summary.

What each protects against, specifically

The plain mean weights every value equally in the sum, so one extreme transaction can shift it substantially; a trimmed mean removes the most extreme values entirely before averaging, which is simple but throws away potentially real information at the tails. A winsorized mean keeps every observation but caps the extreme ones at a threshold, preserving the row count while limiting any single point's influence, a useful middle ground when you don't want to discard rows outright. MAD replaces both the center (the median) and the spread calculation with something that isn't sensitive to a handful of extreme values the way variance is, since the median of a bunch of moderate values plus one extreme one barely moves.

Worked example

Twelve values representing transaction sizes: mostly clustered between 11 and 15, with one value of 250. The plain mean comes out to 32.75, badly distorted by that single value; the median is 13.0, essentially unaffected. A 10% trimmed mean comes out to 13.2, very close to the median, having simply excluded the most extreme values from each end before averaging. The winsorized version (capping the top and bottom 10% at the next-most-extreme retained value) gives a mean of 13.25, similarly close to the median while still using every row. The MAD, scaled to be comparable to a standard deviation on normal data, comes out to about 1.48, a genuinely honest measure of the typical spread among the twelve values, in stark contrast to what the standard deviation (dominated by that single 250) would report.

Trade-offs and pitfalls

Trimming and winsorizing require choosing a percentage to trim or cap at, which is itself a judgment call, not free of assumptions; too aggressive a trim can discard real, meaningful extreme values along with true anomalies. Always report which robust method you used and at what threshold, since "robust mean" without that detail hides a real analytical choice.

Direct answer

Give concrete, structural changes tied to the specific root causes of the original project, not vague platitudes like "communicate more," and be ready to say which of those changes you've actually applied since.

Structured elaboration

Specificity bar
"I'd test more" is a weak answer. "I'd add a data-quality gate before the dashboard build starts" is a strong one. Name the mechanism, not the sentiment.

Categories to draw from
Technical or architecture choices, process or tooling, and stakeholder alignment (definitions, cadence). A strong answer usually touches more than one category, which shows you diagnosed broadly instead of reaching for the easiest lesson.

One question, several framings
This question covers the same underlying move whether it's asked as "what would you do differently," "how would you redesign this system today," or "what changed after you got critical feedback": name the retrospective insight and the concrete change it produced.

Close the loop
State whether you've actually applied the change since. This is what separates a rehearsed lesson from a real one.

Worked example

Original project: an analytics dashboard project where attribution gaps and inconsistent metric definitions surfaced only after launch.

Technical change: build a documented, versioned data model with defined event names and IDs up front, instead of ad hoc joins across sources that let downstream numbers drift out of sync.

Process change: add automated data-quality checks (null, duplicate, schema-drift checks) before any dashboard ships, instead of discovering issues after stakeholders start using the numbers.

Stakeholder change: run a metric-definition alignment session at the start of the project (what counts as a conversion, what attribution window applies) instead of assuming shared understanding.

Applied since: I now start every analytics project with a one-page data contract that stakeholders review before any building starts, which is a direct result of this project.

Trade-offs & pitfalls

• A generic lesson that could apply to any project signals you haven't actually diagnosed root causes.
• Naming only a technical fix and ignoring the process or communication cause (or the reverse), when the original failure had more than one cause.
• Claiming a change you've never actually implemented since; interviewers often ask directly whether it stuck.

Top-down vs bottom-up are complementary forecasting approaches.

Top-down

• What: Start from macro-level (company-wide targets, market size, trend) and allocate to segments.
• When preferable: Early-stage planning, limited granular data, or aligning to strategic targets (e.g., investor guidance).
• Concrete calculation: Apply an expected market growth rate and company market share to project revenue: NextQuarterRevenue = MarketSize_nextQ * ExpectedMarketShare.
• Common pitfall: Overly relying on high-level assumptions (e.g., market share) can ignore operational constraints and lead to optimistic forecasts.
• Example: Leadership sets a target 12% YoY growth in TAM. Current quarterly TAM = $500M → TAM_nextQ = $560M. If company expects to hold 2% share → Forecast = $560M * 2% = $11.2M for next quarter.

Bottom-up

• What: Aggregate granular drivers (units, prices, conversion rates, churn) from products/customers to build total revenue.
• When preferable: Strong transaction-level data, need for operational levers, or scenario testing by product/region.
• Concrete calculation: Sum product-level expected sales: NextQuarterRevenue = Σ (AvgPrice_i * ExpectedUnits_i * (1 − ChurnRate_i)).
• Common pitfall: Garbage-in-garbage-out — inaccurate unit-level estimates or ignoring seasonality/discounting leads to biased totals.
• Example: Product A: 1,000 units * $50 = $50k; Product B: 500 units * $200 = $100k; subtract expected returns/churn 5% → Forecast ≈ ($150k)*(0.95) = $142.5k.

Best practice: Use both — top-down to validate reasonableness and bottom-up for operational detail; reconcile differences, document assumptions, and run sensitivity/scenario analysis.

Use a STAR skeleton (Situation, Task, Action, Result), with the Action being the six questions themselves, since the deliverable the question is asking for is the question set.

Situation: A non-technical stakeholder, for example a VP of Marketing, asks for "a dashboard to track user engagement," with no metric, no user scope, and no cadence attached.

Task: Convert that into a fully specified, buildable requirement before any dashboard work starts, without making the stakeholder feel interrogated.

Action, at least six targeted questions across the six categories asked for:

1. Metric definitions: "When you say 'engagement,' is there one primary action you'd consider a real sign of it, for example completing a key action like posting or logging a session, versus something that looks similar but shouldn't count, like opening the app and closing it within a few seconds? Is this a single metric or a composite of a few actions?"
2. Segmentation: "Do you need this broken out by segment, for example acquisition channel, subscription plan, or account age (new users versus users past their 90-day mark), or is one blended, company-wide number enough for now?"
3. Time granularity: "Should figures be shown daily, weekly, or monthly, and if weekly, do you mean a rolling 7-day window or a fixed Monday-to-Sunday calendar week? Those produce visibly different numbers from the same underlying events."
4. Frequency: "How often do you need this to refresh, real-time, daily, or weekly, and is that driven by how often you'll actually check it or by a fixed reporting cadence like a weekly leadership review?"
5. Business decisions: "What would you do differently depending on what this dashboard shows, for example would a dip trigger a specific action, or is this mainly for status reporting upward? If there's no decision it would change, that's worth knowing before we build it."
6. Data availability: "Is the event data behind this already instrumented and reliable, meaning do we already log the specific actions you care about, or would new tracking need to be added first, which changes the timeline?"

Result: With those six answered, for example the stakeholder says the metric is weekly active users performing a defined key action, segmented only by acquisition channel, shown as a Monday-to-Sunday weekly view refreshed daily but reviewed at the Monday leadership sync, tied to a decision that a sustained flat-or-declining growth rate for 2 consecutive weeks triggers a channel-spend shift, and the underlying key-action events are already logged, the vague ask becomes a fully specified, one-week build instead of an open-ended project that risks shipping the wrong thing.

The same six-category question set works outside a marketing context. A support-operations leader asking for "a dashboard on ticket health" would get the identical treatment: what counts as unhealthy (metric definition, for example first-response time over a stated threshold), broken out by which queue or tier (segmentation), shown daily or weekly (time granularity), refreshed how often (frequency), tied to what staffing or escalation decision (business decision), and whether first-response timestamps are already captured cleanly in the ticketing system (data availability).

What separates a strong answer from a mediocre one: a mediocre answer asks one broad question, "what do you mean by engagement," gets an equally vague answer back, and never converges, or asks several questions that all cluster around metric definitions while never asking about the business decision or data availability, which risks building something polished that nobody acts on or that can't actually be populated with real data. A strong answer spans all six categories, phrases each as something you'd actually say to a non-technical person rather than a jargon-heavy category label, and includes at least one question that is explicitly decision-forcing, tying the dashboard to an action the stakeholder will take, not just a number they'll look at.

Direct answer: Writing the retention common table expression (CTE, a named WITH-clause subquery) and window-function pipeline is the easy 20%. At hundreds of millions of users, running it from raw events every night is the part that doesn't survive contact with production: the fix is to pre-aggregate raw events into a compact per-user-week activity table, partition that table (and the final matrix) by cohort or activity week so a write only ever touches the weeks it affects, and materialize the 12x12 retention matrix as a small table refreshed incrementally rather than recomputed from scratch. The two-sequential-event cohort assignment (signup, then a later onboarding-completed) and late-arriving backfill are really the same design problem in miniature: both require the pipeline to know precisely which slice of the matrix a given late-arriving event can possibly affect, so it only recomputes that slice.

Structured elaboration

Why nightly-from-raw-events doesn't scale: a retention matrix is a slow-moving key performance indicator, or KPI (it changes by a handful of new signups and a week's worth of new activity each night), but a from-scratch pipeline pays for scanning the entire multi-hundred-million-row, multi-week history every single run, more than 99% of which is unchanged from the previous night. The fix is incremental processing on top of a pre-aggregated, partitioned base table, not a faster version of the same full scan.

Performance strategy, in order of impact:

1. Pre-aggregate first. Collapse raw events (many rows per user per day) into user_week_activity(user_id, activity_week) once. This is the single biggest cardinality reduction: bounded by users x weeks, not users x events.
2. Partition by the dimension that changes. New activity this week affects every past cohort's retention row simultaneously (a user from a 10-week-old cohort being active this week updates that cohort's week-10 column), so partition/cluster user_week_activity by activity_week, and only append this week's slice. The matrix update for a given cohort_week + week_offset cell then follows directly from who was active in the newly-appended activity week and what their cohort_week was, which only requires touching users active that week, not the full user base.
3. Materialize the matrix as its own small table. 12 cohorts x 12 offsets is at most ~144 rows; refresh it with a MERGE/upsert against the incremental user_week_activity delta, and let dashboards read the small table, never the raw events.
4. Reserve sampling for exploration only. Approximate counts (e.g. HyperLogLog-style distinct estimators, a family of algorithms that trade a small, bounded error for counting distinct users in a fraction of the memory an exact count would need) are fine for an analyst poking at trends, but a nightly authoritative retention number is exactly the kind of metric (often reported externally or to leadership) where "approximately right" silently erodes trust if it doesn't reconcile with billing or engagement counts elsewhere.

Two-sequential-event cohort assignment (signup, then onboarding-completed): a cohort here isn't a single timestamp, it's the resolution of two ordered events for the same user. A LATERAL join expresses this cleanly:

WITH signups AS (
  SELECT user_id, MIN(event_time) AS signup_time
  FROM events WHERE event_type = 'signup'
  GROUP BY user_id
)
SELECT s.user_id, s.signup_time, ob.onboarding_time,
       DATE_TRUNC('week', ob.onboarding_time) AS cohort_week
FROM signups s
JOIN LATERAL (
  SELECT MIN(e.event_time) AS onboarding_time
  FROM events e
  WHERE e.user_id = s.user_id
    AND e.event_type = 'onboarding_completed'
    AND e.event_time >= s.signup_time
) ob ON ob.onboarding_time IS NOT NULL
ORDER BY s.user_id;

The ON ob.onboarding_time IS NOT NULL turns this into an inner-join-like filter: a user who signed up but never completed onboarding gets no cohort assignment at all, which is correct (they can't be placed on a retention matrix keyed by a week they never reached). A plain window-function alternative (e.g. a filtered MIN() OVER, or LEAD with a type filter) works too; LATERAL makes the "find the qualifying later event" condition explicit and lets an index on (user_id, event_type, event_time) serve it directly. This is a meaningfully different, stricter rule than a simpler daily first-touch cohort assignment (cohort_week = the week of a user's very first event of any kind, with no second qualifying event required); first-touch assignment never has an "unassigned" user, while the two-sequential-event rule always will, for anyone who never reaches step two, and that population needs to be tracked and reported on its own, not silently folded into "week 0 retention."

Late-arriving events and backfill without a full recompute: the failure mode to avoid is treating "backfill" as "rerun the whole pipeline." Instead, track which cohort_week partitions a batch of newly-arrived events actually touches, and MERGE only those:

• A late activity event for an existing cohort only dirties one (cohort_week, week_offset) cell: the user's own cohort_week and the offset implied by the late event's own week.
• A late onboarding_completed event is more dangerous, because it can retroactively change which cohort a user belongs to (a user with no prior cohort assignment now gets one, or one assigned to a wrong/placeholder cohort now moves). The dirty set for that user is the union of their old cohort_week (if any) and their new one; recompute both, not just the partition the late event's own timestamp falls in.
• A per-batch "touched cohort_weeks" list (derived from DATE_TRUNC('week', <the relevant event time>) on just the newly-arrived rows) is cheap to compute and is exactly what should drive the MERGE's WHERE/target-partition scope.

Worked example (executed in DuckDB)

Three events for two users: user 1 signs up 2026-01-01, completes onboarding 2026-01-03; user 2 signs up and completes onboarding both on 2026-01-02; user 3 signs up 2026-01-05 but never completes onboarding. Running the LATERAL cohort query above returns exactly two rows (users 1 and 2, both assigned cohort_week = 2025-12-29, the Monday-starting week containing their onboarding completion), and correctly omits user 3. A late-arriving onboarding event for user 2 at 2026-01-02 20:00 resolves to DATE_TRUNC('week', ...) = 2025-12-29, giving exactly the one dirty partition that a backfill job would need to re-MERGE, not the whole table.

Trade-offs & pitfalls

• Partitioning only by cohort_week (and not also by activity_week) is a common half-measure: it makes backfilling a mis-assigned cohort cheap, but doesn't help the every-night append of new activity, which is naturally keyed by activity_week instead.
• A recursive common table expression (recursive CTE, one that refers to itself to build a result iteratively; Postgres requires the RECURSIVE keyword explicitly, SQL Server does not) can generate the 0..11 week-offset series inline instead of a stored numbers/calendar table, but a small reusable calendar table is usually the better production choice: it's index-friendly and shared across every query that needs a week series, where a recursive CTE regenerates the same series from scratch each time it's used.
• Forgetting to widen the dirty-partition set to include a user's previous cohort_week when a late onboarding event reassigns them is the single most common backfill bug in this pattern: it leaves a stale, too-high retention count sitting in the old cohort's row.

Direct answer
"Unclear requirements" is a real cause sometimes and a convenient explanation other times, so the first job is figuring out which, using evidence rather than taking the explanation at face value. Look at the pattern across several instances, not just the latest miss, separate estimation problems from execution problems from actual requirement gaps, then fix the specific mechanism, not the person's attitude.

Diagnose using the pattern, not the excuse

• Pull several recent examples, not just the most recent miss. Was the requirement genuinely ambiguous every time, or does "unclear requirements" get invoked even when the ticket had clear acceptance criteria? The former is a process problem; the latter is a signal something else is going on (confidence, avoidance, poor estimation).
• Look for where in the workflow it breaks down: did they ask clarifying questions before starting and get bad answers, or did they not ask and guess? Did the requirement change mid-task without being re-scoped? Did they commit to something they didn't actually understand, to avoid looking behind?

Separate the possible root causes

• Genuine ambiguity: the requirement really was underspecified and nobody caught it before work started.
• Estimation or planning gap: the requirement was clear but the person didn't break it down enough to notice the ambiguous parts until they hit them.
• Avoidance: asking clarifying questions feels risky (looks like not knowing), so they guess and then have a ready explanation when it goes wrong.
• Skill gap under a different name: they may not yet have the judgment to know what "clear enough to start" looks like.

Fix the mechanism that matches the cause

• Genuine ambiguity: introduce a lightweight definition-of-ready check before work starts, owned jointly, not something you police alone.
• Estimation or planning: practice breaking a ticket into sub-tasks together and flag the ambiguous piece explicitly before committing to a date.
• Avoidance: make asking clarifying questions cheap and normal, model it yourself, and separate "I don't know yet" from an evaluation of competence.
• Skill gap: pair on a couple of tickets so they see what "clear enough" actually looks like in practice, rather than being told about it abstractly.

Worked example
A mentee on a team I supported kept missing sprint commitments, and the stated reason was always some version of unclear requirements. Looking at the last four tickets together, not just the most recent one, a pattern showed up: on three of the four, the acceptance criteria were actually written clearly, but the mentee hadn't asked any clarifying questions before starting, then hit an edge case mid-task and treated the whole ticket as ambiguous from the start. On the fourth, the ticket genuinely was underspecified.

The fix wasn't "communicate more clearly" in the abstract. It was two things: a short pre-work check where we'd both look at a ticket before it was picked up and flag anything genuinely unclear (catching the real ambiguity case), and a habit of the mentee sending one clarifying question per ticket before starting, even a small one, to break the avoidance pattern. The signal it was working wasn't a single metric; it was that "unclear requirements" stopped being the explanation for misses, because the real ambiguity was being caught earlier and the avoidance pattern had a lower-stakes outlet.

Trade-offs and pitfalls

• Taking "unclear requirements" at face value every time lets a deeper issue (avoidance, skill gap) hide behind a plausible-sounding excuse indefinitely.
• Assuming it's never true is just as wrong; requirements genuinely are underspecified sometimes, and treating every instance as a character problem erodes trust.
• The fix has to match the actual cause. A definition-of-ready checklist won't help someone avoiding asking questions, and coaching someone to "just ask more" won't help if the requirements really were bad.