Meta Data Analyst Interview Preparation Guide (Mid-Level, 2026)

Direct answer
Most large employers that codify their interview values name broadly similar underlying traits, even when their specific vocabulary differs: a customer or user-first orientation, taking ownership beyond a narrow scope, moving with appropriate urgency, holding a high quality bar, and being trustworthy and transparent recur across nearly every published framework, just under different labels.

Structured elaboration

Worked example
The table above is itself the worked example. A strong candidate should be able to reproduce a table like this from memory for whichever specific company's list they are asked about, translating each of that company's named principles onto one of these five underlying traits, rather than treating an unfamiliar company's vocabulary as an entirely new set of ideas to learn from scratch.

Trade-offs and pitfalls
Treating every company's list as identical is itself a mistake; the values differ in emphasis, and in what is explicitly left off the list. A company whose published list omits any explicit ownership language may culturally deprioritize individual initiative in favor of process, for example, and that is worth noticing rather than flattening away. A candidate who can only speak the vocabulary of one company, fluent in one set of terms but unable to translate the same underlying trait into a different company's language, reads as having memorized rather than internalized the competencies involved.

Risk 1 — Market competition / customer churn
Project: Competitive Churn & Winback Dashboard

• Goal: Detect rising churn attributable to competitor activity; quantify lost ARR and prioritize retention.
• Required data: customer subscription history, churn reasons (CSAT), NPS, product usage logs, pricing/promotions timeline, competitor pricing/events (scraped or third-party), marketing touchpoints.
• Owner: Growth Analytics (Data Analyst) with Product & CRM as stakeholders; escalation to Head of Growth.
• Key metrics & thresholds:
  • Monthly churn rate > baseline + 1.5ppt for two consecutive months → investigate.
  • % churn citing “price/competitor” > 25% of exit surveys in a month.
  • Decline in weekly DAU of high-value cohorts > 10% week-over-week.
• Alerting rules: Automated email + Slack alert when thresholds hit; include top 5 affected cohorts and recent competitor events.
• Reporting cadence: Weekly dashboard for Growth; deep-dive report monthly with recommended retention experiments.

Risk 2 — Product reliability / platform incidents
Project: Product Health & Incident Early-Warning System

• Goal: Monitor reliability signals to reduce MTTR and customer impact.
• Required data: error logs, API latency, uptime, incident tickets, user-reported complaints, session drop-offs, infrastructure alerts.
• Owner: Data Analyst (Reliability) partnering with SRE and Product.
• Key metrics & thresholds:
  • 95th percentile API latency > 500ms for 10 minutes.
  • Error rate spike: errors/sec > 3x 1-hour moving average.
  • New incident tickets from 5+ unique customers in 30 minutes.
• Alerting rules: PagerDuty for SRE on immediate threshold breach; Slack channel summary for Product and Support with affected endpoints and user impact.
• Reporting cadence: Real-time alerts; post-incident root-cause report within 48 hours; weekly reliability scorecard.

Risk 3 — Regulatory / compliance exposure (data privacy)
Project: Data Privacy Compliance Monitor

• Goal: Detect anomalous access/exfiltration and compliance gaps before fines or breaches.
• Required data: access logs, data export logs, PII labeling, consent records, audit logs, privacy requests (DSAR), regional user counts.
• Owner: Data Analyst (Compliance) with Legal & InfoSec owners; Compliance officer for escalation.
• Key metrics & thresholds:
  • Unusual data export volume per user > baseline + 5σ.
  • Increase in DSARs > 30% month-over-month.
  • Percentage of datasets missing consent metadata > 2% of production datasets.
• Alerting rules: Immediate encrypted alert to InfoSec and Legal on export anomalies; weekly digest of consent gaps.
• Reporting cadence: Daily anomaly checks; weekly compliance dashboard; monthly executive summary with remediation status.

Across all projects: implement automated ETL pipelines, documented data lineage, and playbooks for triage. Prioritize dashboards built in BI tool with drilldowns so stakeholders can act quickly.

Direct answer

A strong answer shows you built a case, not just found a number. You named the default decision that was about to happen without evidence, matched the weight of evidence to how reversible the decision was and how much time you had, triangulated quantitative and qualitative signal so the "what" and the "why" both showed up, and packaged the result as a decision artifact the stakeholder could act on, not a data dump they had to interpret themselves.

Structured elaboration

Anatomy of an evidence-based case:

1. Name the default. Say plainly what decision is about to happen and why (usually intuition, urgency, or one compelling anecdote), so the room can see the gap you're filling.
2. Match evidence weight to reversibility and time. An irreversible, expensive decision earns more rigor; a near-term deadline earns the fastest credible signal, not the most rigorous one.
3. Triangulate. Quantitative data shows what is happening; qualitative signal (interviews, quotes, support tickets) shows why. Either alone invites the obvious rebuttal ("that's just anecdotes" or "the numbers don't say why").
4. Package for the audience. A one-page decision memo or a single slide often does more persuasive work than another week of analysis.

Worked calculation: honest uncertainty. Say a pilot of 200 users produced 30 conversions ($\hat p = 0.15$). Reporting the point estimate alone overstates confidence; a senior candidate reports a confidence interval instead, a range you can say you are 95% sure the true value falls in, rather than presenting one number as if it were exact. The 1.96 is the cutoff that corresponds to 95% confidence under a normal approximation (the assumption that many possible outcomes cluster into the familiar bell-curve shape, where about 95% of that curve falls within 1.96 standard errors of the estimate), and the term under the square root is the standard error, a measure of how much this estimate would move around if the pilot were rerun on a fresh sample:

$$\hat p = \frac{30}{200} = 0.15$$ $$CI_{95\%} = \hat p \pm 1.96\sqrt{\frac{\hat p(1-\hat p)}{n}} = 0.15 \pm 1.96\sqrt{\frac{0.15 \times 0.85}{200}} \approx 0.15 \pm 0.05 = [0.10,\ 0.20]$$

Saying "10% to 20%, most likely around 15%" instead of a bare "15%" is what separates a credible business case from a fabricated-precision one, and it pre-empts the "is this even real" objection a numerate stakeholder will raise.

Same move, different packaging. This competency shows up in many shapes across roles, and the table below is a reference, not a checklist to work through row by row: skim it once for the pattern, then treat the worked example further down as the one version you actually need to know cold. The underlying move (evidence proportional to stakes, triangulated, packaged to persuade) stays the same in every row:

Worked example

Situation. At a mid-size B2B platform team, leadership was two weeks from locking next quarter's roadmap around a reporting-and-analytics overhaul, driven by one executive's belief that power users needed deeper reports to upgrade. Meanwhile, early trial cancellations were climbing and nobody had looked at why.

Stakes. Committing a full quarter of engineering capacity to the wrong bet, while trial users kept leaving faster than new demand could replace them, would have made growth slower, not faster, than the reporting bet was even meant to fix.

The influence moves.

• Named the default out loud, as a factual gap rather than an accusation: the roadmap was currently being decided on one executive's hypothesis with no supporting signal.
• Matched evidence to the window: with only ten days before the roadmap locked, pulled existing product-analytics event data (already collected, no new instrumentation needed) and ran a short opt-in exit survey to the last 60 days of canceled trials.
• Triangulated: the event data showed where in onboarding users dropped off; the survey free-text explained why. Of 40 respondents, 27 cited setup and configuration confusion as their reason for leaving ($27 \div 40 = 0.675$, about 68%), not a missing feature.
• Packaged it as a one-page decision brief: one paragraph stating the ask ("delay the reporting overhaul one quarter, fix onboarding setup friction instead") plus a short evidence appendix (the funnel chart and three verbatim quotes), not a slide-by-slide walkthrough.
• Sized the ask to the evidence: proposed a two-week spike to fix the worst setup step and re-measure, rather than asking for a permanent reroute of the whole quarter on ten days of analysis.

Resolution. Leadership approved the two-week spike before the roadmap locked. The evidence was credible enough that the original executive co-sponsored the change instead of contesting it.

What a senior candidate does differently. A mid-level candidate stops once the numbers "prove" the point. A senior candidate also stages the ask so it's proportionate to how much evidence they actually had, and brings the original stakeholder along as a co-sponsor rather than a defeated opponent, which is what protects the relationship for the next disagreement.

Trade-offs and pitfalls

• Rigor vs. speed. Over-investing in statistical proof for a reversible, low-stakes call wastes the one resource (time and goodwill) that a genuinely irreversible call actually needs.
• Data dump vs. artifact. A wall of dashboards is not persuasive on its own; the packaging (one slide, a two-part memo) often does more work than an extra week of analysis.
• Causal overclaim. Claiming a change "caused" a metric improvement without ruling out confounders (seasonality, concurrent launches) is the fastest way to lose credibility with a numerate stakeholder. Name the confidence and the caveats instead of hiding them.
• Thin-signal cases. Treat a severe but thin (n<10) signal as grounds for a bounded, reversible action (a pilot, a spike), not a full commitment. Conflating "worth investigating now" with "proven" is a common junior mistake.

Direct answer

Given three internal dashboards with very different daily-user counts, weekly retention, and time-spent figures, the first step is to recognize that "unhealthy" means something different for each: a dashboard can look weak on one dimension while actually serving its purpose well on another, so the diagnosis has to be dashboard-specific rather than a single ranked list.

Structured elaboration

Consider the pattern each dashboard is showing on its own terms. A dashboard with high daily users but low weekly retention and short average time suggests people check it briefly and often but are not finding deep, lasting value there, which fits an alerting or status-check use case reasonably well and may not actually be unhealthy for that purpose. A dashboard with low daily users but high weekly retention and short time suggests a small, dedicated audience that returns reliably for a quick, specific check, which also may be healthy for its intended purpose (an executive summary that a handful of leaders check briefly but consistently). A dashboard with moderate-to-high daily users but low weekly retention and very short time suggests the weakest pattern of the three: frequent but shallow, low-commitment usage with no sign of a dedicated returning base, which most plausibly indicates either the content is not actionable enough to justify a return visit or the audience does not yet trust it enough to rely on it.

The diagnosis should be paired with the tool's INTENDED purpose before recommending fixes, since a low-retention, high-frequency alerting tool being "fixed" toward higher retention may be optimizing for the wrong outcome entirely.

Worked example

Suppose the three dashboards show the following adoption metrics this quarter (a sales-overview dashboard with 150 daily users, 40% weekly retention, and 6 minutes average time; an executive-KPI dashboard with 40 daily users, 85% weekly retention, and 3 minutes average time; and an operations-alerts dashboard with 220 daily users, 25% weekly retention, and 2 minutes average time): the operations-alerts dashboard is the one that most needs attention: its retention is the lowest of the three (25%) despite having the most daily traffic, and its short average time combined with low retention suggests users check it reactively rather than building it into a routine. Four practical actions to raise adoption, value, and retention for the weaker dashboards: (1) for operations-alerts, interview a sample of users who stopped returning to find out whether the alerts shown are actionable or just noisy; (2) add a lightweight "what changed since your last visit" summary to reduce the cost of returning, which tends to help retention on frequently-updated dashboards specifically; (3) for the sales-overview dashboard, check whether its moderate retention (40%) reflects a genuinely useful but under-adopted tool that would benefit from a targeted rollout push rather than a content change; (4) across all three, instrument which specific sections or filters get used versus ignored, since a dashboard-level retention number cannot show which parts of the dashboard are actually earning the return visits.

Trade-offs and pitfalls

The main risk is applying a single "increase retention" playbook uniformly to all three tools without first checking whether low retention is actually a problem for that specific tool's use case; forcing a quick-glance alerting tool to optimize for longer, more frequent return visits could make it worse at its actual job. A second pitfall is treating the daily-user count as automatically the most important number; a small, highly retained audience (like the executive-KPI dashboard) can represent a healthier and more defensible use case than a larger but shallow one, even though the larger number looks more impressive at a glance.

Direct answer

Turning an unowned, recurring problem into a durable model means naming the exact boundary of what's being owned, assigning one accountable owner (not a committee) with a real SLA, building in automated enforcement rather than relying on memory, and setting up a recurring, visible check specifically so the gap can't quietly reopen once initial attention moves elsewhere.

Structured elaboration

• Define clear boundaries and SLAs. Write down exactly what's in scope in specific terms, not a broad category. A specific, checkable boundary is what makes an SLA (an agreed commitment, like a turnaround time or a compliance bar) possible to hold anyone accountable to; a vague boundary makes accountability impossible to enforce.
• Assign and enforce accountability. One named owner, with a documented backup, reporting into whichever existing leadership structure already makes sense rather than inventing a new one. Enforcement means an automated check that verifies the thing is actually happening, plus a defined escalation path for when it isn't, rather than trusting the owner to remember on their own.
• Verify over time that the gap doesn't reopen. A recurring audit, reported somewhere visible on a regular cadence, so a new lapse shows up as a visible trend rather than silence, which is exactly how the original problem became unowned in the first place.

Worked example

A data-retention policy requiring deletion of raw customer PII (personally identifiable information) after 90 days exists on paper but nobody actually enforces it. An audit finds 6 of 14 identified data stores retaining data past 90 days, one of them for over a year.

• Boundary: scope is defined precisely as 90-day PII retention across these 14 identified data stores, explicitly excluding already-aggregated or anonymized data, which is a separate and lower-risk category.
• Owner: one data engineer is named the accountable owner, with a documented backup, reporting into the existing data governance lead rather than a newly invented reporting line.
• SLA: all 14 stores compliant within 60 days of the fix being proposed, and any newly onboarded data store added to the automated scan within 2 weeks of going live.
• Enforcement: an automated weekly scan checks each store's oldest retained record and pages the owner if any store exceeds 90 days, rather than relying on someone remembering a manual quarterly check.
• Verification over time: a quarterly compliance report (stores compliant out of 14) is shown at the existing data governance review, so a future lapse appears as a visible trend rather than silence, which is exactly how the original 6 of 14 non-compliant stores went unnoticed for as long as they did.

The same four-part model, a specific boundary, a single accountable owner, automated enforcement, and durable verification, applies just as directly to the other unowned-problem triggers named here. An unowned on-call rotation gets the same treatment: the boundary is which services and hours it covers, the owner is accountable for a defined response-time SLA, enforcement is an automated paging check rather than a hope that someone notices, and verification is a recurring review of missed-page incidents. Defining end-to-end ownership for a data pipeline uses the identical shape: the boundary runs from source ingestion to the final consumed table, not just the code a given engineer happens to have written, and the owner is accountable for both data quality and pipeline uptime across that entire span. Compliance ownership split loosely across architecture, engineering, and legal gets the same fix with region-specific SLAs where local regulation genuinely differs, rather than one global standard applied uniformly where it doesn't actually fit. A reporting backlog nobody prioritized gets the identical treatment: the boundary is the specific set of reports and their required refresh or delivery cadence, the owner is a named analyst or reporting lead accountable for a queue-age SLA (for example, no request open longer than 10 business days), enforcement is an automated queue-age check that flags any request approaching that limit, and verification is a recurring review of the backlog's age distribution, so a growing backlog shows up as a visible trend rather than being discovered only when a stakeholder complains it's been ignored for months.

Trade-offs and pitfalls

The most common failure is defining the boundary too broadly, assigning someone data governance in general instead of a specific, checkable scope, which makes accountability impossible to actually enforce. A second failure is assigning an owner without building in automated enforcement, which quietly reverts to the original ad hoc state once the person's attention moves to the next priority. Watch also for treating the initial fix as the end of the work: without the recurring, visible audit, the exact same gap reopens quietly, often taking just as long to notice the second time as it did the first.

Join the parent aggregate to the sum of its children and flag any pair whose difference exceeds a small floating-point tolerance, treating a strict equality check as almost always the wrong choice for numeric data that's passed through any arithmetic at all.

Approach (verified by execution)

```sql
SELECT o.order_id, o.total_amount, SUM(oi.amount) AS items_sum,
ABS(o.total_amount - SUM(oi.amount)) AS diff
FROM orders o
JOIN order_items oi ON o.order_id = oi.order_id
GROUP BY o.order_id, o.total_amount
HAVING ABS(o.total_amount - SUM(oi.amount)) > 0.01;
```

Worked example (verified by execution)

An order recorded with `total_amount = 55.00` whose line items sum to `49.99` produces a diff of `5.01`, well past the 0.01 tolerance, correctly surfacing as a violation; a second order whose total matches its line items exactly does not appear in the result at all.

Trade-offs and pitfalls

The same invariant-checking shape (a recorded total versus a computed sum of its parts) generalizes to checking that a day's hourly metric values sum to the recorded daily total, and to checking that a dimension's full set of expected values still appears in a daily aggregate even on a day with zero activity for one of them (so a category doesn't silently vanish from a report rather than showing a legitimate zero). A related but distinct check worth running alongside this one is completeness of PAYMENT against an order's expected total, which needs its own comparison (partial or missing payments) rather than being folded into the same query, since "the order total doesn't match its line items" and "the order hasn't been fully paid" are different failures with different remediation paths even though both compare a recorded amount to an expected one.

1. Control for multiple testing

• Pre-specify primary metric(s) and label others as secondary/exploratory. Only control Type I for primary.
• For secondary metrics, use False Discovery Rate (Benjamini–Hochberg) to limit expected proportion of false positives when assessing many outcomes; use Bonferroni or Holm for conservative family-wise error if false positives are costly (legal/financial).
• Consider hierarchical testing: test grouped families in order (primary first, then familywise secondaries) to preserve power.
• Report raw p-values, adjusted p-values, and effect sizes with CIs; emphasize practical significance.

2. Decide whether to ship

• Use a decision rule combining statistical and business criteria:
  • Primary metric: must meet pre-specified significance/power and minimal detectable effect (MDE).
  • Guardrails: critical secondaries (e.g., retention, revenue) must not show harmful effects beyond pre-specified thresholds.
  • Cost-benefit: estimate expected value = delta_primary * revenue_per_unit − costs from adverse secondary impacts. Use Bayesian decision framework to incorporate uncertainty.
• If primary wins but some secondaries move adverse yet non-conclusive after multiple-testing correction, prefer caution: delay full roll-out, partial roll-out, or phased rollout with close monitoring.

3. Follow-up experiment / observational analysis

• Design a confirmatory A/B with pre-registered hypotheses for affected secondaries, powered to detect the observed effects (use observed SDs to compute sample size).
• Use stratified or blocked randomization on covariates correlated with ambiguous metrics to reduce variance.
• Consider factorial design to test interactions if multiple changes occurred.
• Use sequential testing with alpha spending (e.g., O’Brien–Fleming) if you need interim decisions.
• Observational analyses: run regression adjustment, difference-in-differences, and propensity-score methods on larger historical data to assess mechanisms; perform mediation analysis to see if primary effect flows through a secondary.
• Always run subgroup and sanity checks, surface heterogeneous treatment effects, and report pre-specified thresholds and FDR-adjusted results so stakeholders can make an informed, quantified decision.

Situation: We propose an analytics initiative to standardize performance measurement (new revenue recognition smoothing, normalized KPIs, and automated dashboards). It will improve decision quality but may temporarily reduce reported revenue volatility as we move from ad-hoc metrics to normalized, comparable measures.

ROI:

• Faster, better decisions → estimated 2–4% revenue uplift annually from improved price/product mix and faster churn mitigation (model-backed).
• Cost savings: automate 80% of manual reporting → ~$300k/year in analyst hours and error reduction.
• Payback in 9–12 months (implementation cost: tooling + 2 FTEs + one-time ETL cleanup).

Risk mitigation:

• Phased rollout to avoid board surprise; dual-reporting (legacy and normalized) for 3 quarters.
• Communication plan and training to align incentive structures.
• Validation: parallel-test new metrics against historical outcomes and external benchmarks.
• Audit trail and governance to ensure reproducibility.

Stakeholder impacts:

• Finance: temporary reconciling work; gains in forecasting accuracy.
• Sales/Product: clearer KPI alignment, minor incentive recalibration.
• Leadership/Board: clearer long-term performance signals; short-term variance reduction explained via dual-reporting.

Pilot plan (90 days):

1. Week 0–2: Requirements + data inventory (SQL/ETL scope).
2. Week 3–6: Build canonical data model and normalization rules; implement automated ETL.
3. Week 7–10: Dashboard prototype (Power BI/Tableau) and parallel reporting.
4. Week 11–12: Validation, stakeholder demos, revise.
5. Month 4–6: Expand to full roll-out with training and governance.

KPIs delivered post-launch:

• Forecast accuracy (MAPE) improvement to <8% within 6 months.
• Time-to-report reduced from 5 days to <24 hours.
• Percent automated reports: 80%+
• Decision-impact metrics: revenue uplift attributable to analytics (quarterly), churn reduction %
• Data quality metrics: completeness >99%, error rate <0.5%

I will lead the data work: SQL-driven ETL, validation, and dashboards; coordinate with Finance for reconciliation and with HR for incentive alignment. This approach balances transparency, business continuity, and measurable upside.

Direct answer

Ownership should follow causal control, not who asked for the metric. A number that only one team's actions actually move belongs to that team as a leading indicator. A number that several teams jointly move needs to be treated as a shared outcome with exactly one canonical definition that everyone points to, not each team computing its own version of 'the same' number.

Structured elaboration

1. Decide ownership by who controls the number

Ask: if this metric moved tomorrow, whose decisions would most plausibly explain it? If the answer is one team, it's team-owned. If the honest answer is 'several teams, depending on the week,' it's a shared outcome metric and needs shared governance, not a single team's dashboard.

2. Give every shared metric one canonical definition

Store the computation (the query or transformation logic) in one place, documented with an owner, a last-updated date, and the exact filters and date logic used. Any dashboard or report showing that metric should read from that canonical source, not recompute it independently.

3. When two teams report different numbers, reconcile, don't debate

The canonical definition is the tiebreaker by default. If a mismatch appears, the fix is a reconciliation step: compare the two calculations side by side, find where the logic diverges (a different date window, a different filter, a stale cache), and correct the deviating one, or update the canonical definition itself if it turns out to be wrong. Either way, log the decision so the same disagreement doesn't restart from zero next quarter.

4. Put governance around who can change a shared definition

A shared metric's definition should not change because one team unilaterally decides a different cohort or window looks better. Route changes through a lightweight review involving everyone who reports on that metric, and version the definition so historical numbers can be explained if they shift after a redefinition.

Worked example

A dashboard spans data engineering, product, and marketing for a signup-to-paid-conversion initiative. Splitting ownership this way keeps the dashboard honest:

When marketing's report shows a different sign-up count than the shared dashboard, the reconciliation step finds that marketing's number excluded a promo-code cohort by mistake. The canonical query is correct; marketing's ad hoc report is fixed to match it, and the discrepancy is logged so the next person who notices a mismatch can find the resolution instead of reopening the debate.

Trade-offs and pitfalls

• Centralizing every metric, including team-level leading indicators, slows down the teams that need to iterate quickly on their own signals; only the genuinely shared outcomes need the heavier canonical-definition process.
• Fully decentralizing shared outcome metrics guarantees mismatched dashboards eventually, which quietly erodes trust in the data even when the underlying numbers are directionally fine.
• A 'single source of truth' only works if using an alternate calculation is treated as a defect to fix, not a valid difference of opinion; without that enforcement, teams drift back to their own numbers within a quarter.
• Late-arriving corrections that change historical values need an explicit policy (do dashboards restate history, or only apply corrections going forward) decided in advance, or every correction becomes its own dispute.

Parentheses change what OR groups with, and SQL's default precedence (AND binds tighter than OR) can silently produce the wrong result if you assume left-to-right reading.

Structured elaboration

Without parentheses, WHERE category = 'shirts' AND price < 20 OR on_sale = true is evaluated as (category = 'shirts' AND price < 20) OR (on_sale = true): any row that is on sale qualifies, category and price notwithstanding. Adding parentheses around the OR, category = 'shirts' AND (price < 20 OR on_sale = true), restricts the OR branch to shirts only. Neither form is "wrong" in isolation; the bug is writing one when you meant the other. NOT is the third operator the question names, and its precedence is the highest of the three: SQL evaluates NOT before AND, and AND before OR. So NOT category = 'shirts' AND price < 20 parses as (NOT category = 'shirts') AND (price < 20), not as NOT (category = 'shirts' AND price < 20); the NOT applies only to the single comparison immediately next to it, not to the whole AND expression, unless parentheses say otherwise.

Worked example

Using products(product_id, category, price, on_sale) with rows (1, shirts, 15, not on sale), (2, shirts, 25, on sale), (3, pants, 10, on sale), (4, shirts, 30, not on sale):

• Without parentheses: rows 1, 2, 3 match. Row 3 (pants) sneaks in purely because it's on sale.
• With parentheses: rows 1, 2 match. Row 3 is correctly excluded because it isn't a shirt.
• Adding NOT: WHERE NOT category = 'shirts' AND price < 20 matches only row 3 (pants, price 10). The NOT applies to category = 'shirts' alone (true for rows 1, 2, 4, so NOT makes it false for them), then ANDs that with price < 20, leaving only the one row that is both not-a-shirt and under $20. Wrapping the whole expression instead, WHERE NOT (category = 'shirts' AND price < 20), flips which rows are excluded: it matches rows 2, 3, and 4, everything except row 1 (the only row where category = 'shirts' AND price < 20 was true to begin with).

Trade-offs and pitfalls

The fix costs nothing and the failure mode is silent (no error, just wrong rows), which is what makes it dangerous in report queries nobody double-checks. As a habit: whenever AND and OR appear in the same WHERE clause, add explicit parentheses even where they aren't strictly required, purely for the next reader. The same silent-wrong-result risk applies to NOT: many people mentally read NOT a AND b as NOT (a AND b), but SQL does not; when NOT needs to negate a whole compound condition rather than just the term next to it, parenthesize it explicitly.