Netflix Data Scientist Interview Preparation Guide - Junior Level

Direct answer
In sixty to ninety seconds, state what the work was and the concrete outcome in the first sentence, then use the remaining time to give just enough context for the outcome to make sense, without narrating the full journey.

Structured elaboration

1. Lead with outcome, not chronology. Start with what changed as a result of the work, not "so first we looked into..."; the listener's attention is highest in the first five seconds, so spend it on the punchline, not the preamble.
2. Give one sentence of context, just enough for a listener unfamiliar with the project to understand why the outcome mattered.
3. Name the concrete result. A number, a capability that now exists, or a problem that's now solved, stated plainly rather than hedged.
4. Leave a natural opening for a follow-up question, rather than trying to cram in every detail; a pitch that answers every possible question leaves nothing for the listener to ask, which can feel like a wall rather than a conversation.
5. Practice against a clock. Sixty seconds is shorter than it feels; a written script read at a natural pace is the fastest way to find out where it actually runs long.

Worked example
"I led the project to move our nightly batch reports to a real-time pipeline. Before this, finance waited until 9am for the previous day's numbers; now they're available within about five minutes of the event happening. It took about six weeks and meant migrating three internal tools onto the new pipeline, which is the part I'm happy to go deeper on if useful."

Outcome and its concrete magnitude come in the first two sentences (roughly 9am wait to about five minutes), then one sentence of scope, then an explicit invitation to go deeper rather than continuing to add detail.

Trade-offs and pitfalls

• The most common failure is starting with the setup ("so basically what happened was...") instead of the outcome, which spends the highest-attention seconds on the least important part.
• Cramming in every detail to sound thorough usually makes the pitch run long and diluted; a pitch that leaves a natural question is often more effective than one that tries to be exhaustive.
• Precision matters more than the exact wording; if you don't have a hard number, say so honestly ("noticeably faster, though I don't have an exact percentage") rather than inventing a specific-sounding figure you can't back up.

Direct answer

Hours and chapters completed tell me about effort, not capability, so I look for checkpoints tied to a real deliverable instead. The clearest version of that: can I predict what a specific change will do before I make it, not just explain the topic afterward.

Structured elaboration

Proxy indicators I actually use, since a single perfect signal doesn't exist, each with its own weakness:

• Shipping an independent piece of work in the area, with no help. Strong signal, but slow to obtain, so it's not useful early on.
• Review comments on my work in that area thinning out over time. Weaker signal, since a reviewer having less to say could mean I've improved, or that they're tired that week.
• Being able to explain or predict the outcome of a specific case correctly before checking. This is the one I trust most, because it's falsifiable in the moment.
• Doing a representative task in roughly the time a competent person would, without help. An objective, outside-visible signal, but it only kicks in once you're already close to proficient, so it's a late-stage check, not an early one.

There's a real difference between the bar for having an informed opinion in a discussion, which I reach fairly early, and the bar for owning something live and unsupervised, which takes much longer and requires more than one of the signals above to line up.

Noticing a plateau matters as much as tracking progress: if the signals stop moving for a while, that's the point to change approach rather than keep doing more of the same thing that got me this far.

Reporting honestly when the timeline slips: when my original estimate for reaching proficiency turns out to be wrong, I say so directly rather than quietly redefining what "ready" means to make the original deadline look accurate.

Worked example

The last thing I taught myself was a specific observability approach for diagnosing a class of production issue. Early on, my main signal was whether I could predict what a trace would show before opening it, which was slow and often wrong at first. After a couple of weeks I noticed that signal had plateaued, so I changed approach: instead of reading more source material, I started shadowing a real live investigation someone else was running. That unstuck it. I originally estimated I'd be comfortable owning this unsupervised within three weeks; it actually took closer to five, and I said so plainly to my lead rather than letting the definition of "comfortable" quietly drift to match the original date.

Trade-offs and pitfalls

The common failure here is treating hours invested or a certificate of completion as proof of readiness, since both measure activity, not capability. Each proxy above also has a specific failure mode worth naming honestly rather than presenting any single one as sufficient on its own.

Direct answer

Compute a pairwise similarity score across the specified key columns using a fuzzy string-matching library, flag pairs above a threshold as near-duplicates, and use blocking to keep the comparison tractable rather than checking every possible pair.

Structured elaboration

import pandas as pd
from rapidfuzz import fuzz

def find_near_duplicates(df, subset_cols, threshold=90, block_col=None):
    """Return a list of (idx_a, idx_b, score) for row pairs whose combined similarity
    across subset_cols exceeds threshold. block_col, if given, restricts comparisons to
    rows sharing the same block_col value, avoiding an all-pairs scan."""
    results = []
    groups = df.groupby(block_col) if block_col else [(None, df)]
    for _, group in groups:
        rows = group[subset_cols].astype(str).agg(" ".join, axis=1)
        idxs = rows.index.tolist()
        for i in range(len(idxs)):
            for j in range(i + 1, len(idxs)):
                score = fuzz.token_set_ratio(rows.iloc[i], rows.iloc[j])
                if score >= threshold:
                    results.append((idxs[i], idxs[j], score))
    return results

df = pd.DataFrame({
    "name": ["John Smith", "Jon Smith", "Alice Lee", "Alicia Lee"],
    "zip": ["10001", "10001", "94105", "94105"],
})
dupes = find_near_duplicates(df, subset_cols=["name"], threshold=85, block_col="zip")
print(dupes)

Blocking strategy to reduce $O(n^2)$ comparisons: grouping by a coarse, cheap-to-compute key (zip in the example above) means fuzzy scoring only runs within each group rather than across the whole dataset, turning an infeasible all-pairs comparison on a large table into a sum of much smaller within-block comparisons; choosing a blocking key that's reliable (unlikely to itself be wrong or missing for true duplicate pairs) is what keeps this from silently dropping real duplicates.

For scaling to millions of rows: parallelize across blocks (each block's within-group comparison is independent and can run on a separate worker), and for a genuinely enormous dataset, consider a cheaper first-pass filter (a minhash or locality-sensitive-hashing scheme) to generate CANDIDATE pairs even faster than exact blocking, before running the more expensive fuzzy string comparison only on that reduced candidate set.

Worked example

Running the code above at threshold=85, "John Smith" and "Jon Smith" (both in zip 10001) score 94.7 on token_set_ratio and get flagged, while "Alice Lee" and "Alicia Lee" (zip 94105) score only 84.2, just under the threshold, and are correctly left unflagged, a concrete illustration of why the threshold value itself is a real precision/recall lever worth tuning rather than picking arbitrarily. No cross-zip comparisons are attempted at all, since blocking by zip keeps John/Jon Smith from ever being compared against Alice/Alicia Lee in the first place.

Trade-offs and pitfalls

The most common bug in this class of function is an inefficient nested loop over the FULL (unblocked) dataset, which works fine on a small test set and then becomes impractically slow the moment it's run on real production-scale data; validating performance on a realistically-sized sample, not just a small toy example, is worth doing before this ships.

Direct answer: Order each user's page views by time, use LEAD to look at the next event's page and timestamp, and keep rows where the current page is 'A', the next page is 'B', and the time between them is within 10 minutes. Because LEAD only looks at the immediately following row per user, this only matches A directly followed by B, not A followed eventually by B with other pages in between. Generalizing to a longer chain (a 3-step funnel) means chaining multiple LEAD calls, one per step, each with its own offset.

Structured elaboration

WITH ordered AS (
  SELECT user_id, page, viewed_at,
    LEAD(page) OVER (PARTITION BY user_id ORDER BY viewed_at) AS next_page,
    LEAD(viewed_at) OVER (PARTITION BY user_id ORDER BY viewed_at) AS next_viewed_at
  FROM page_views
)
SELECT user_id, viewed_at AS a_time, next_viewed_at AS b_time
FROM ordered
WHERE page = 'A' AND next_page = 'B'
  AND next_viewed_at <= viewed_at + INTERVAL '10 minutes';

Worked example (executed in DuckDB). User 1: A at 10:00, B at 10:05 (5-minute gap, qualifies). User 2: A at 11:00, B at 11:25 (25-minute gap, does not qualify).

user_id | a_time   | b_time
1       | 10:00:00 | 10:05:00

Only user 1 appears in the result: user 2's A-then-B pair is correctly excluded because 25 minutes exceeds the 10-minute window, even though B genuinely followed A in their event stream.

Generalizing to a longer chain (a 3-step funnel). Two workable shapes:

1. Stacked LEAD offsets in one CTE (common table expression: a named, temporary result set defined with WITH ... AS (...) that the rest of the query can reference like a table). LEAD(page, 1) and LEAD(viewed_at, 1) give the next event, LEAD(page, 2) and LEAD(viewed_at, 2) give the one after that. Filtering page = 'A' AND LEAD(page,1) = 'B' AND LEAD(page,2) = 'C' (plus a time bound between the first and last step) finds users whose next two events, in order, were exactly B then C.
2. Chained CTEs, one per step, each filtering down to users who completed the previous step, then joining forward to the next page within the window: a landing-page common table expression, then an add-to-cart one that self-joins to it on user_id and a time bound, then a purchase one the same way. This is more verbose but scales cleanly to N steps without adding a new LEAD(page, k) term for every step, and it reads closer to how a funnel is usually described ("how many made it from step 2 to step 3").

-- Stacked-LEAD version of a 3-step A -> B -> C funnel within 30 minutes total
WITH ordered AS (
  SELECT user_id, page, viewed_at,
    LEAD(page,1) OVER (PARTITION BY user_id ORDER BY viewed_at) AS p2,
    LEAD(viewed_at,1) OVER (PARTITION BY user_id ORDER BY viewed_at) AS t2,
    LEAD(page,2) OVER (PARTITION BY user_id ORDER BY viewed_at) AS p3,
    LEAD(viewed_at,2) OVER (PARTITION BY user_id ORDER BY viewed_at) AS t3
  FROM page_views
)
SELECT user_id, viewed_at AS a_time, t2 AS b_time, t3 AS c_time
FROM ordered
WHERE page = 'A' AND p2 = 'B' AND p3 = 'C'
  AND t3 <= viewed_at + INTERVAL '30 minutes';

Run against a 3-event chain for user 1 (A 10:00, B 10:05, C 10:12), this returns exactly that one row with a_time=10:00, b_time=10:05, c_time=10:12, confirming the offset chain correctly threads through all three steps in order.

Trade-offs & pitfalls

• Requiring the events to be immediately consecutive (via LEAD(...,1), LEAD(...,2)) is a strict funnel definition: a stray click on an unrelated page between A and B breaks the match. If the real requirement is "A eventually followed by B, other pages allowed in between," you need a different construction: the first B-or-later event after each A, found via a window frame or a self-join with a MIN, not sequential LEAD offsets.
• Stacked LEAD(page, k) terms don't scale gracefully past a handful of steps; a 10-step funnel is more maintainable as chained CTEs or a recursive approach than ten hardcoded LEAD(page, k) columns.
• Watch for a user who visits A multiple times in a row before B; this query matches every A immediately followed by B, so a user with A, A, B produces one qualifying pair (the second A to B), not necessarily the one you intended if you wanted "first A to first B" specifically.

Direct answer

The key design choice is randomizing at a unit large enough to contain the cross-side spillover a price or fee change creates: typically a market cluster (a geography, city, or self-contained supply region) rather than individual buyers or individual sellers, because a marketplace's two sides interact through the same local supply-demand pool. Within that, you deliberately vary treatment intensity across clusters (a partial-saturation or dose-response design) so you can separate the direct pricing effect from the cross-side externality it triggers, and you plan the revenue read as a staged measurement: an early operational window for the direct effect, followed by a longer holdout-based window because churn and re-equilibration on a two-sided market take longer to surface than a single-user metric would.

Structured elaboration

Why buyer-only or seller-only randomization fails here

If you randomize individual sellers into a higher take rate, a treated seller may raise prices, list less, or churn; buyers who would have transacted with that seller instead transact with a control-arm seller in the same market. The buyer side is now indirectly treated regardless of which arm assigned it, which is the same SUTVA-style interference problem as a social feed, except the shared medium is the local marketplace instead of a social graph. Randomizing individual buyers has the mirror-image problem on the seller side. Either choice contaminates the arm you intended to leave clean.

Randomization scheme

• Unit: market cluster (geography, city, or another boundary where most matching happens locally, e.g., delivery radius). This keeps most buyer-seller matching internal to a single treatment condition.
• Design shape: partial saturation. Instead of a flat 50/50 split, assign clusters to a small number of treatment intensities (for example, no increase, a modest increase, a larger increase) rather than a single on/off arm. This lets you trace how the cross-side response scales with the size of the change, which a single treatment level cannot distinguish from a fixed step change.
• Randomize at the cluster level, stratified on baseline liquidity (existing buyer-to-seller ratio, transaction volume) so clusters that already look structurally different are balanced across intensities before you start, reducing the chance that a treatment-intensity effect is confounded with a pre-existing market difference.

Detecting and quantifying the cross-side externality

• Because clusters are internally exposed to one intensity, you can compare a directly-treated side's metric (e.g., seller take-rate exposure) against the other side's metric within the same cluster (buyer conversion, buyer price sensitivity) to see if the fee change on sellers moved buyer-side behavior, and by how much, as intensity increases.
• The partial-saturation design turns this into a dose-response check: plot the buyer-side metric against assigned intensity across clusters. A flat line across intensities is evidence of a contained direct effect; a sloped line is direct, in-cluster measurement of the spillover, not an assumption about its existence.
• Compare a cluster's realized outcome to adjacent, untreated clusters it plausibly shares supply with (e.g., neighboring cities where sellers can relist), which is a direct check for leakage across the cluster boundary itself, not just across sides within a cluster.

Estimating the long-run revenue impact

• Short-run direct revenue (immediate take-rate math: transactions times the new fee) is mechanical and available immediately, but it is not the number that matters, because it ignores behavioral response.
• The number that matters is the net of three components measured over a longer window: the direct fee revenue, minus revenue lost to seller churn or delisting, minus revenue lost to buyer-side friction from any resulting price or availability change. Each of these three needs its own time horizon: fee revenue is immediate, seller churn plays out over weeks as sellers decide whether to stay, and buyer-side effects play out over the buyer's own return cadence.
• Because of that lag structure, hold a subset of clusters as a long-run holdout past the point where you make the initial ship decision. This is what lets you catch delayed seller attrition or buyer defection that would not have shown up in an early readout, and it is a standard practice for any monetization change with a plausible slow-churn tail, not something specific to marketplaces.

Worked example

A delivery marketplace tests a take-rate increase across 40 city clusters, split into two treatment intensities plus control (roughly 13-14 clusters each, stratified on baseline order volume so the three groups start with comparable liquidity). At the direct level, transaction-weighted take-rate revenue rises with intensity, as expected mechanically. The diagnostic step is checking buyer-side order volume within the same clusters: if buyer order volume also declines with intensity (a negative slope across the three intensity levels, measured, not assumed), that decline is the in-cluster, dose-response evidence of the cross-side externality: sellers responded to the higher take rate by raising prices or delisting, and buyers responded to that. The ship decision then nets the two effects (higher unit take rate, lower volume) into an actual revenue trajectory rather than trusting the mechanical fee-revenue number alone.

Trade-offs and pitfalls

• Cluster randomization costs statistical power relative to individual-level randomization, because the effective sample size is the number of clusters, which is typically far smaller than the number of users; this needs a longer test or fewer, larger clusters, and it is a real cost you should state up front rather than discover after the fact.
• A short observation window will understate the true cost of the change, because seller churn and buyer defection both lag the price change; shipping on the early direct-revenue number alone is the single most common mistake in this design.
• Neighboring-cluster leakage (a seller in a treated city relisting in an adjacent control city) is a real risk for marketplaces with mobile supply; check it explicitly rather than assuming cluster boundaries are airtight.
• Resist reaching for a full structural or instrumental-variable model as the default; those are appropriate when randomization is genuinely unavailable, but the partial-saturation cluster design above gives a directly measured effect and should be preferred whenever you can actually randomize.

Direct answer. Build one confusion tally per class in a single O(n) pass over the paired label arrays, then derive per-class precision/recall/F1 plus micro and macro averages from those tallies in O(k) time, where k is the number of distinct classes.

Code (executed and verified against scikit-learn's per-class, micro, and macro F1).

import numpy as np

def per_class_prf1(y_true, y_pred):
    y_true = np.asarray(y_true)
    y_pred = np.asarray(y_pred)
    classes = np.union1d(np.unique(y_true), np.unique(y_pred))  # handles classes missing from either side
    idx = {c: i for i, c in enumerate(classes)}
    k = len(classes)
    tp = np.zeros(k); fp = np.zeros(k); fn = np.zeros(k)
    for yt, yp in zip(y_true, y_pred):
        if yt == yp:
            tp[idx[yt]] += 1
        else:
            fp[idx[yp]] += 1
            fn[idx[yt]] += 1
    precision = np.divide(tp, tp + fp, out=np.zeros(k), where=(tp + fp) > 0)
    recall = np.divide(tp, tp + fn, out=np.zeros(k), where=(tp + fn) > 0)
    f1 = np.divide(2 * precision * recall, precision + recall, out=np.zeros(k), where=(precision + recall) > 0)
    micro_p = tp.sum() / (tp.sum() + fp.sum()) if (tp.sum() + fp.sum()) > 0 else 0.0
    micro_r = tp.sum() / (tp.sum() + fn.sum()) if (tp.sum() + fn.sum()) > 0 else 0.0
    micro_f1 = 2 * micro_p * micro_r / (micro_p + micro_r) if (micro_p + micro_r) > 0 else 0.0
    return dict(classes=classes.tolist(), precision=precision.tolist(),
                recall=recall.tolist(), f1=f1.tolist(), micro_f1=micro_f1, macro_f1=float(f1.mean()))

Worked example (recomputed against scikit-learn). On a 10-example, 3-class sample, this returns per-class F1 = [0.857, 0.75, 0.8], micro F1 = 0.800, macro F1 = 0.802; scikit-learn's precision_recall_fscore_support and f1_score(..., average='micro'/'macro') return the identical numbers to 1e-9.

Structured elaboration: complexity and edge cases. The single loop over the n paired labels is O(n); building the class index and computing the vectorized precision/recall/F1 arrays is O(k). np.union1d over BOTH the true and predicted label sets, not just y_true, is what correctly handles a class that the model predicted at least once but that never actually appears in y_true in this batch (or vice versa): without it, that class would silently disappear from the output instead of showing up with a defined (likely 0) precision or recall.

Trade-offs and pitfalls. Micro-F1 aggregates all classes' TP/FP/FN before computing one global precision and recall, so it's dominated by whichever class has the most examples; macro-F1 averages the PER-CLASS F1 scores unweighted, so a rare but important class counts exactly as much as a common one. If you present only micro-F1 for a screening task with a rare, critical class, a model that ignores that class entirely can still look fine.

Direct answer

Put the validation gate immediately before the point the dashboard actually reads from, not just at ingestion, and split checks into two tiers: cheap, structural checks (schema, row count, null rate) that block promotion synchronously because they are fast enough to never skip, and expensive, statistical checks (distribution drift, cross-source reconciliation) that run asynchronously and only block when they cross a hard severity threshold. That tiering is what lets every normal run stay fast while still catching the rare bad one.

Structured elaboration

Placement matters as much as the checks themselves. A check that runs somewhere upstream in the pipeline, but not immediately before promotion to what the dashboard reads, can be bypassed by any path that skips that stage: a manual hotfix, a one-off reload. The gate has to sit at the boundary between internal pipeline state and what is allowed to be read externally, typically a staging table or view that only gets promoted after passing.

Severity-based routing: not every failed check should halt the pipeline or page someone. Classify checks as hard-fail (never publish, a negative revenue figure) versus soft-fail (publish but annotate the dashboard and route to on-call for review), so a borderline, plausible-but-flagged check does not hold every normal run hostage the way a hard-fail check should.

Circuit breaker for the gate itself: if the last several promotions have failed validation, or the gate errors out, fail safe by continuing to serve the last known-good snapshot rather than either blocking indefinitely or letting unvalidated data through by default.

Worked example

A daily automated report pipeline extracts, aggregates, and then runs structural checks before promoting to the reporting table that feeds an automated email summary. Trailing 7-day average row count is 120,000 rows/day; the structural check allows a plus-or-minus 10% band:

$120{,}000 \times 1.10 = 132{,}000 \qquad 120{,}000 \times 0.90 = 108{,}000$

A run producing 40,000 rows, a 67% drop, falls far outside [108,000, 132,000], so it is held automatically and the email summary is not sent; the pipeline owner is alerted with the specific failed check, and last night's report keeps serving as the current version until someone resolves it. No human has to eyeball the report first to catch this kind of failure.

flowchart LR
  source --> aggregate
  aggregate --> structural{structural checks}
  structural -->|pass| staging
  structural -->|fail| hold["hold + alert owner"]
  staging --> statcheck["async statistical checks"]
  statcheck -->|severe| hold
  statcheck -->|ok or advisory| promote
  promote --> dashboard
  hold --> lastgood["serve last known-good"]
  lastgood --> dashboard

Trade-offs & pitfalls

Making every check synchronous and blocking would slow down every normal run to catch a rare bad one, exactly the cost the question is asking to avoid; tiering by cost, not removing checks, is the actual fix. Routing every failed check to a page burns out on-call and trains people to ignore alerts, the same alert-fatigue failure mode as over-notifying on any correction policy. A gate that only lives at ingestion misses corruption introduced by a later transformation step; the check has to sit right before the path the dashboard actually reads, or a later bug slips through untouched.

Direct answer: For turning text into model features, bag-of-words/term-frequency-inverse-document-frequency (TF-IDF) is cheap, interpretable, and a strong baseline for many classification tasks; pretrained static embeddings capture some semantic similarity at modest cost; contextual (transformer-based) embeddings capture the most nuanced meaning but at meaningfully higher storage, latency, and serving cost, so the right choice depends heavily on the accuracy the task actually needs versus the latency and cost budget available.

Structured elaboration:

• Bag-of-words/TF-IDF: represents text as sparse word/n-gram counts, weighted to downweight common words. Fast, interpretable (you can point to which term drove a prediction), no training required beyond fitting the vocabulary, but blind to word order and synonymy ("great" and "excellent" are unrelated dimensions).
• Pretrained static embeddings (word2vec/GloVe-style): each word gets a fixed dense vector capturing some distributional similarity, typically averaged or pooled into a document vector. Captures synonymy that TF-IDF misses, at a fixed, moderate storage and compute cost, but still ignores context (the same word gets the same vector regardless of surrounding meaning).
• Contextual embeddings (transformer-based): the vector for a word or document depends on its surrounding context, capturing meaning far more precisely (disambiguating a word's sense from context), at substantially higher compute cost to produce and larger storage per document, which matters directly for online serving latency and cost at scale.

Fine-tuning versus using embeddings frozen is a separate axis: fine-tuning end-to-end on the target task usually improves accuracy further but multiplies training cost and risks overfitting on a small labeled dataset; frozen embeddings used as fixed features are cheaper and more robust when labeled data is limited.

Worked example: A product-search relevance model with a tight latency budget and moderate accuracy needs might do best with TF-IDF or a cached, precomputed static embedding, since contextual embeddings computed at query time would blow the latency budget; a smaller-volume, accuracy-critical classification task (say, content moderation) with room for heavier per-item compute is a better fit for contextual embeddings, since the accuracy gain is worth the added serving cost there.

Trade-offs and pitfalls: Caching and quantizing embeddings (precomputing them offline rather than at request time, and storing them at reduced precision) is often the practical way to get most of a heavier method's accuracy benefit without paying its full serving-time cost, and is worth considering before defaulting to the cheapest option purely on latency grounds.

Direct answer

Don't treat it as narrative versus dashboard, give both, but change which one is the default view. Lead with a short narrative stating the decision-relevant takeaway, and keep the full dashboard one click or one slide away so the stakeholder can self-serve or verify a number without you gatekeeping the underlying data.

Structured elaboration

• Diagnose why they want the full dashboard. It could be distrust of your synthesis, a habit from before narrative summaries existed, or a genuine need to slice the data themselves.
• If it's distrust, that is a relationship problem to fix with a track record of accurate synthesis over time, not a formatting problem you can solve in one deliverable.
• If it's a genuine self-serve need, make the narrative the front page and link the dashboard as the appendix rather than dropping the narrative altogether.

Worked example

A BI analyst's sponsor insists on seeing the full 40-metric dashboard every week. The analyst starts sending a 3-bullet narrative email ("signups up 8% week over week, driven by the paid channel; retention flat; one metric to watch, refund rate ticked up half a point") with the dashboard link at the bottom. After a month the sponsor mostly replies to the narrative and stops opening the dashboard link most weeks, but keeps it available for the weeks they want to check a specific number themselves.

Trade-offs and pitfalls

Removing the detailed view entirely risks looking like you're hiding something. Always leading with the raw dashboard loses your chance to frame the interpretation, and the stakeholder may draw their own, sometimes wrong, conclusions from the unframed numbers.

What the interviewer probes next

Expect a follow-up on what you'd do if a stakeholder explicitly says they don't trust your narrative and want to see everything raw, every time.

LIKE treats % and _ as wildcards, so to match them as literal characters you need an ESCAPE clause.

Structured elaboration

SELECT email FROM users
WHERE email LIKE '%\_%' ESCAPE '\';

The backslash before the underscore tells the engine "this next character is literal, not a wildcard", because ESCAPE '' declares backslash as the escape character for this pattern. Without the escape, _ would match any single character, so LIKE '%_%' alone matches virtually every non-empty email, not just ones containing a literal underscore.

Worked example

Given emails 'a_b@x.com', 'aXb@x.com', 'a%b@x.com': the escaped pattern correctly matches only 'a_b@x.com'. Without the escape clause, all three would match (the _ wildcard matches the X and the % in the other two rows).

For the percent case, given the same three emails plus 'acb@x.com' (no special character at all): the escaped pattern LIKE '%\%%' ESCAPE '\' matches only 'a%b@x.com'. 'a_b@x.com', 'aXb@x.com', and 'acb@x.com' are all correctly excluded, since none of them contain a literal percent sign. Without the escape, an unescaped % wildcard matches zero or more of any character, so a pattern like LIKE '%%' matches every row regardless of content, the same false-positive failure mode as the unescaped underscore case above.

Trade-offs and pitfalls

The exact escape syntax differs slightly by engine (PostgreSQL and MySQL both support ESCAPE; SQL Server does too), but the concept is standard SQL. For matching a literal %, use the same technique: LIKE '%\%%' ESCAPE '\'. If a column regularly contains characters that need escaping, a regex-based match (~ in Postgres, REGEXP in MySQL) is often more readable than juggling escape characters in LIKE.