DoorDash Data Scientist Interview Preparation Guide - Junior Level

Direct answer: Frequency encoding replaces each category with how often it occurs (as a raw count or a normalized proportion), which is cheap, fixed-size regardless of cardinality, and needs no training-time-vs-serving-time complexity, but the same simplicity is exactly what causes its production pitfalls at high cardinality or when the training and serving populations differ.

Structured elaboration:
The implementation: group by the categorical column, compute each category's count (or count divided by total rows, for a normalized frequency), and map each row to its category's computed value. This is a simple, deterministic, table-lookup-style transform once fit on training data.

Worked example: Verified: applying frequency encoding to a small categorical column (['a','a','b','c','a','b']) correctly assigns 'a' a frequency of 0.5 (occurring 3 of 6 times), 'b' a frequency of 0.333 (2 of 6), and 'c' a frequency of 0.167 (1 of 6), confirming the encoding correctly reflects each category's relative prevalence in the fitted data.

Trade-offs and pitfalls: At high cardinality, frequency encoding suffers the same COLLAPSING problem discussed for other encodings in this topic: two entirely distinct categories that happen to occur with the same frequency become indistinguishable to the model, purely by coincidence of prevalence, not any real similarity between them. More importantly for production: if the training-time and serving-time populations differ (a category that was rare in training suddenly becomes common in a later period, or vice versa), the frequency encoding computed once at training time becomes STALE, silently misrepresenting a category's current true prevalence; this is a genuine, easy-to-miss instance of training-serving skew specific to this encoding, and argues for periodically refreshing the fitted frequencies (with a defined, deliberate cadence) rather than treating them as a one-time, forever-fixed lookup.

Direct answer

I paraphrase the feedback back in my own words before doing anything else with it. Saying it back does two things at once: it proves to the other person I actually understood (rather than nodded along), and it often surfaces a mismatch between what they meant and what I heard before I've gone and acted on the wrong interpretation.

Structured elaboration

The technique itself is simple: after hearing a piece of feedback, restate the core of it in your own words, framed as a check rather than a repeat, and pause for confirmation before moving on. This is different from just repeating their words back verbatim, which can feel robotic and doesn't actually prove understanding; paraphrasing forces you to process the meaning, not just the sounds.

It matters most exactly when feedback is even slightly ambiguous, which is more often than it seems, because people frequently give feedback assuming shared context that isn't actually shared. A quick paraphrase costs seconds and prevents the much more expensive failure mode of confidently building the wrong fix.

Worked example

In a code review, a reviewer says: "this function is doing too much." I'd paraphrase: "so you're saying I should split the validation logic out from the actual processing, is that the split you had in mind, or something different?" That single sentence confirms my read of "doing too much" (which could have meant several different things: too many responsibilities, too long, poorly named) and gives them an easy chance to correct me before I go rewrite the function around the wrong interpretation.

Trade-offs and pitfalls

Paraphrasing everything, even feedback that was already completely unambiguous, slows the conversation down and can read as stalling rather than clarifying; it's most useful specifically when there's real room for multiple interpretations. Paraphrasing in a flat, mechanical way (repeating their exact words back) misses the point of the technique, since it doesn't actually demonstrate you processed the meaning. And treating a confirmed paraphrase as license to stop listening for anything further is its own trap; the technique confirms one point, it doesn't close the conversation.

Unnest every top-level key across all rows in one pass, and aggregate per key: its inferred type, how often it's present, and a small sample of actual values, so you understand the real shape of inconsistent JSON before designing a stricter schema for it.

Approach

```sql
WITH keys AS (
SELECT json_keys(payload) AS ks, payload FROM raw_events
),
unnested AS (
SELECT UNNEST(ks) AS key_name, payload FROM keys
)
SELECT key_name,
COUNT(*) AS non_null_occurrences,
MODE(json_type(json_extract(payload, '$.' || key_name))) AS inferred_type,
ARRAY_AGG(json_extract(payload, '$.' || key_name))[1:3] AS sample_values
FROM unnested
GROUP BY key_name
ORDER BY non_null_occurrences DESC;
```
`json_keys` lists every top-level key present in a given row's payload, so unnesting across all rows and grouping by key name gives you, in one pass, exactly which keys exist across the whole dataset and how consistently.

Worked example

Across 1,000 rows, a key like `user_id` might appear in all 1,000 (always typed as an integer), while a key like `promo_code` appears in only 40 rows and shows a MIXED inferred type (sometimes a string, sometimes null-typed because it's absent), immediately telling you `promo_code` is optional and needs type-coercion handling wherever it's consumed downstream.

Trade-offs and pitfalls

`MODE()` on the inferred type picks the MOST COMMON type per key, which can mask real type inconsistency within that key (a numeric field that's occasionally sent as a string); if type consistency itself is what you're validating, report the DISTINCT set of observed types per key, not just the mode, so a key with genuinely mixed types is visible rather than silently summarized away. This schema-inference query is a useful first pass before designing a stricter, declared validation (checking specific required keys exist and specific values cast correctly), which is a separate, narrower query once you know what "correct" should look like for this payload.

Direct answer: Frame the story around the specific evidence that changed your mind, not just the outcome: what the feature was doing when you called it, what data made you confident enough to recommend rolling it back, and what pushback (if any) you navigated to make the call stick.

Structured elaboration

• Situation: set up what the feature was and what it was supposed to do, briefly, so the listener understands the stakes of the decision.
• Task: state what you were responsible for (owning the metric, or being the person who had to make the recommendation) and what made the call non-obvious (early positive signal, organizational excitement, sunk cost).
• Action: describe the specific analysis or signal that convinced you the feature was net-negative (a guardrail metric breaking, a longer-horizon metric turning negative once enough time had passed, a segment where the harm concentrated), and how you communicated the recommendation, including handling any disagreement.
• Result: state what happened after the rollback (the guardrail recovering, or a quantified cost avoided) and, ideally, what changed in how the team measures or launches features afterward as a result of this experience.

Worked example: A candidate describes owning analytics for a checkout redesign that showed a clean, statistically real lift in conversion in its first two weeks. By week four, the candidate noticed refund requests within 14 days had climbed from a 3% baseline to 5.5% among users exposed to the new flow, driven by a confusing step that made users complete purchases they had not fully intended to finish. The candidate brought the refund data to the team, quantified the net revenue effect once refunds were included (turning a nominal conversion win into a net loss once refunds were netted out), and recommended a rollback despite pushback from stakeholders who were excited about the conversion number. The team rolled back within a week, refund rate returned to baseline, and the team adopted a standing rule to track a 14-day refund guardrail on every checkout experiment going forward.

Trade-offs and pitfalls: A weak version of this story stops at "the metric went down so I said roll it back," without showing the specific evidence and reasoning that made the call defensible under pushback; the strongest version shows a metric that looked good getting reinterpreted once a longer window or a guardrail surfaced the real cost. Avoid overstating your personal authority in the decision if you were one voice among several; credit the process (the guardrail existing, the team's willingness to act on it) rather than framing it as a unilateral heroic call.

Direct answer. INTERSECT returns only the rows that appear in BOTH result sets. EXCEPT (MINUS in Oracle) returns the rows that appear in the FIRST result set but not the second. Both compare whole rows, need the same number of columns with compatible types on each side, and both dedup their output.

Structured elaboration. Think of them as set arithmetic over two same-shaped result sets rather than as joins: there's no join key to specify, the entire row IS the comparison unit. That makes them a natural fit for comparing two snapshots or two populations directly, without writing an explicit join condition.

Worked example. customers_2023(customer_id): 1, 2, 3. customers_2024(customer_id): 2, 3, 4.

-- customers present in BOTH years (returning customers)
SELECT customer_id FROM customers_2023
INTERSECT
SELECT customer_id FROM customers_2024;
-- returns 2, 3

-- customers present in 2023 but not 2024 (lost customers)
SELECT customer_id FROM customers_2023
EXCEPT
SELECT customer_id FROM customers_2024;
-- returns 1

Trade-offs and pitfalls. Both operations dedup by default (like UNION, not UNION ALL), so if you need to know HOW MANY TIMES a row appeared rather than just whether it appeared, INTERSECT/EXCEPT are the wrong tool and you need an explicit join or GROUP BY instead. NULLs in the compared columns are handled specially: unlike an ordinary equality comparison, most engines treat two NULLs in the same position as equal for the purposes of this row comparison, which is the opposite of how NULL behaves in a join predicate, and is a common source of confusion when you've internalized "NULL never equals NULL" from working with joins.

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.

Direct answer. Short of full per-tenant partitioning, you have per-tenant or filtered statistics (where the engine supports collecting statistics scoped to a subset of the data), query-time hints or per-tenant query variants that account for known skew, and, more structurally, isolating the most extreme outlier tenants onto their own physical partition while leaving the rest on shared, generically-planned infrastructure; validate whichever you choose by checking plan quality for BOTH the affected outlier tenants and the unaffected majority, not just the one you noticed complaining.

Structured elaboration. Generic, table-wide statistics describe an "average" distribution across every tenant, which works fine for typical tenants but can badly misdescribe an unusually large or unusually skewed tenant's actual data shape, leading the optimizer to a plan tuned for the average case rather than that specific tenant's reality. Filtered or extended statistics, where available, can capture a more nuanced picture (for instance, statistics conditioned on a tenant-identifying column) without requiring full physical separation. Where that's not available or not granular enough, a smaller, more surgical structural change, moving only the handful of genuinely extreme tenants onto dedicated partitions or even dedicated infrastructure, while leaving the long tail of typical tenants on the shared, generically-planned setup, often captures most of the benefit of full per-tenant partitioning at a fraction of the operational cost.

Testing the chosen approach means checking plan quality and query latency for BOTH ends of the distribution: the outlier tenants you're specifically trying to help, AND a sample of typical tenants, to confirm you haven't traded one group's problem for the other group's regression, since a fix tuned too specifically for the outliers' shape can sometimes make plans worse for the previously-fine majority.

Worked example. A multi-tenant analytics platform where 95% of tenants have a few thousand rows each but a handful of enterprise tenants have tens of millions, generic table-wide statistics will describe something close to "typical tenant size," badly misleading the optimizer for both ends: plans tuned for the (statistically dominant, small) typical tenant can be catastrophic for the enterprise tenants, and, less obviously, statistics skewed by including the enterprise tenants' data can occasionally produce suboptimal plans for the typical tenants too.

Trade-offs and pitfalls. Full physical per-tenant partitioning is the most complete fix but also the most operationally expensive, more partitions to manage, more complexity in every cross-tenant query; reach for it only once you've confirmed lighter-weight options (filtered statistics, isolating just the extreme outliers) genuinely aren't sufficient, rather than defaulting to the heaviest solution first.

Situation: The model's error rate has jumped for a specific user segment (e.g., users in Region X). I would use SHAP to find which features' contributions changed for that segment versus baseline and identify the likely root cause.

Steps:

1. Compute instance-level SHAP

• Use the same explainer used in production (TreeExplainer/DeepExplainer/KernelExplainer) and compute SHAP values for: (a) all instances in the failing segment, (b) a baseline set (historical population or recent non-failing users).

2. Aggregate across the segment

• Compute per-feature metrics: mean(SHAP), mean(|SHAP|), median, and the sign proportion (fraction positive vs negative). Capture the distribution (violin/histogram) to see heterogeneity.
• Optionally compute interaction SHAP for top features to detect feature-pair effects.

3. Compare to baseline

• For each feature compute delta = metric_segment minus metric_baseline. Rank features by change in mean(|SHAP|) and change in signed mean to see which features increased in influence or flipped direction.
• Run statistical tests (bootstrap CIs, permutation test, or a t-test if assumptions hold) to verify significance and compute effect sizes.

4. Distinguishing the four possible root causes explicitly

• Real population change: the segment's INPUT feature distributions genuinely shifted (a new user cohort, a seasonal effect, a new device type). Confirm by comparing feature distributions for the segment across time using the raw, non-model data, independent of SHAP. If the SHAP shift tracks a distribution shift that's externally explainable (a marketing campaign, a product launch, a new region), this is the likely cause, and the fix is usually retraining or reweighting rather than a bug hunt.
• Preprocessing bug: the FEATURE VALUES going into the model changed because of a code or pipeline defect (a join breaking, a null-fill changing, a unit change), not because the real world changed. Confirm by re-running the exact preprocessing code on raw logs captured before and after the suspected change and diffing the outputs field by field; a feature that silently changed shape (a categorical suddenly encoded differently, a numeric field's scale shifted by a constant factor) with no real-world reason is a bug, not a population shift.
• Newly introduced leakage: a feature that was NOT available at the true prediction time is now present, or a previously-masked feature briefly saw future or label-correlated information, causing the model to appear to lean on it more heavily. Confirm by explicitly checking the feature's computation window against the label's timestamp for the affected segment (does it use any event at or after the point the label became known?), and by checking whether the SHAP-flagged feature correlates suspiciously strongly with the label -- near-perfect separation is a leakage tell, not a real signal.
• Training artifact: nothing changed in production data at all; the apparent shift is an artifact of HOW SHAP was computed (a different background/reference dataset between the two runs, a different model version, or a small-sample-size segment producing high-variance attributions). Confirm by recomputing SHAP for both time periods with identical explainer settings, background dataset, and model version, and by bootstrapping the segment's SHAP estimates to see if the 'shift' is within noise.
  Only after ruling out the preprocessing-bug, leakage, and training-artifact explanations (all fixable infrastructure issues, not real signal) should the SHAP shift be treated as reflecting a genuine change in the world that the model needs to be retrained or reweighted for.

Caveats when interpreting SHAP changes:

• SHAP is descriptive, not causal: a change in SHAP points to association with model output, not that the feature caused the errors.
• Background/baseline choice matters: SHAP values depend on the background dataset; compare using a consistent baseline or test sensitivity to different baselines.
• Correlated features & interactions: SHAP can apportion importance across correlated inputs but may produce unstable attribution; use interaction SHAP and conditional analyses.
• Sample size and variance: small segments yield high variance; use bootstrap CIs.
• Model changes and explainer consistency: if the model version changed, recompute SHAP with the same explainer settings.
• Computation & approximation: kernel approximations may be noisy; prefer exact explainers for trees or validated approximations.

This process links SHAP-driven signals to a specific, testable root cause among the four candidates above, enabling prioritized, testable remediation (relabeling, retraining, feature fixes, or targeted monitoring) instead of treating every SHAP shift as automatically meaningful.

Direct answer

In a past project, I needed to know whether a new onboarding email sequence actually improved 30-day retention, not just whether it looked better in a dashboard. I framed it as a two-proportion hypothesis test on a randomized A/B split, checked the assumptions behind that test, and then translated the statistically significant result into a dollar figure before recommending a rollout, because a p-value alone doesn't tell a stakeholder whether to spend engineering time shipping it.

Structured elaboration

Hypothesis formulation. With $p_{new}$ and $p_{old}$ as the true 30-day retention rates under each sequence:

I used a two-sided alternative rather than one-sided, because a null result and a negative result both had to be plausible outcomes I'd act on differently.

Design and assumptions. Users were randomized to sequence at signup (independent units, no user sees both), the outcome is binary (retained or not at day 30), and with roughly 12,000 users per arm the sample was large enough for the normal approximation to the binomial to hold. Before running it I did an a priori power calculation targeting 80% power to detect a 2 percentage-point lift at $\alpha = 0.05$, which is what set the run duration and the minimum sample size, so I wasn't deciding "run until it looks good."

Test selection. A two-proportion z-test is the right tool here: two independent binomial samples, testing a difference in proportions, large enough $n$ per arm that the sampling distribution of the difference is well-approximated by a normal.

Worked example

Observed: $n_1 = n_2 = 12{,}000$, $x_{new} = 1{,}584$ retained ((\hat p_{new} = 0.1320)), $x_{old} = 1{,}296$ retained ((\hat p_{old} = 0.1080)). Pooled proportion under $H_0$: $\hat p = (1584+1296)/24000 = 0.1200$.

That gives $p < 0.0001$ (two-sided), computed and verified with scipy.stats.norm.sf. For the effect-size CI I used the unpooled standard error (correct for a confidence interval, as opposed to the pooled SE used for the null-hypothesis test statistic):

giving a 95% CI on the difference of $0.024 \pm 1.96(0.00419) \approx [0.016,\ 0.032]$, or 1.6 to 3.2 percentage points.

Practical significance. A 2.4-point lift on a 12,000-user cohort translates to about 288 additional retained users in that sample alone; scaled to a monthly signup volume, I converted that into an estimated incremental-retention revenue range using the team's existing LTV-per-retained-user assumption, and paired that with the (near-zero) engineering cost of keeping the new sequence live. I presented the CI, not just the point estimate, so stakeholders could see the plausible range of the ROI rather than a single number that implied more precision than the data supported.

Trade-offs & pitfalls

• A p-value this small mostly reflects large $n$; I made a point of leading with the percentage-point lift and its CI, not the p-value, when talking to non-technical stakeholders, because "p < 0.0001" invites false confidence about the size of the effect, not just its existence.
• I checked for novelty effects: a lift that shows up in week one of a new email sequence sometimes fades as users get used to it, so I flagged that the 30-day window doesn't rule out longer-run decay and recommended a follow-up read at 90 days.
• I only had one primary metric locked in the pre-registration; if I'd been peeking at five secondary metrics along the way, I'd have needed a multiple-comparisons correction (Bonferroni or Benjamini-Hochberg) before treating any of those as confirmatory.

Direct answer

Design this as a pre-registered, longitudinal comparison rather than a single before/after read: fix a small number of windows relative to each user's first exposure, not launch date, in advance, fit a simple decay model to the day-by-day treatment effect, and commit to a decision rule, stated before you see the data, for what pattern of the fitted decay and asymptote counts as real and durable versus novelty that will fade. The goal is to make the durable-vs-fading call a mechanical read of a pre-specified model output, not a judgment call made after watching the curve.

Structured elaboration

Time windows to pre-specify

• Baseline (pre-treatment, roughly two weeks before exposure): confirms no pre-existing difference between the groups on the metric of interest.
• Immediate (days 0 to 7 since first exposure): captures the bulk of any novelty spike.
• Short (days 8 to 30): where a genuine novelty component should be visibly decaying.
• Long (days 91 and beyond, or as far out as the experiment can afford to run): the window whose effect is treated as the primary estimate of the persistent effect, used for the launch decision.
  These are anchored to exposure age, days since each user's own first exposure, not calendar date, so users who join on different days are all compared on the same clock. A calendar-date plot mixes freshly exposed and long-exposed users in the same daily bucket and can mask a real decay curve as a false flat line.

Modeling the decay

Fit the daily or weekly treatment effect to a two-parameter decay-to-asymptote form:
$\Delta(t) = C + A e^{-\lambda t}$
where $t$ is exposure age, $C$ is the persistent (asymptotic) effect, $A$ is the size of the transient novelty component, and $\lambda$ is the decay rate. A purely persistent effect looks like $A \approx 0$, flat from day one; a pure novelty artifact looks like $C \approx 0$, decaying to nothing; most real cases land somewhere in between, with both $A$ and $C$ meaningfully nonzero, meaning some of the early lift really does fade but a smaller durable effect remains.

The decision rule, pre-specified

Commit, before the experiment starts, to a rule such as: the effect is durable if the long-window estimate's confidence interval excludes zero and the fitted persistent component $C$'s confidence interval excludes zero, evaluated no earlier than three estimated half-lives, $3 \times \ln 2/\lambda$, after first exposure. This does three things a post-hoc read cannot: it fixes how long to wait based on the shape of the decay itself rather than an arbitrary calendar deadline, it requires the long-window effect to independently clear significance rather than trusting the fitted curve alone, and it removes the temptation to declare victory the moment the curve looks favorable.

Worked example

Suppose a fitted decay model on the immediate and short windows gives stated, illustrative parameter estimates $A = 6\%$, $C = 2\%$, $\lambda = 0.15$ per week. The half-life of the transient component is:
$t_{1/2} = \frac{\ln 2}{\lambda} = \frac{0.693}{0.15} \approx 4.6 \text{ weeks}$
The pre-specified decision rule requires waiting roughly $3 \times 4.6 \approx 13.9$ weeks, call it 14 weeks, before the long-window read is treated as decisive. At that point, the transient component's contribution has decayed to:
$A \cdot e^{-\lambda \cdot 14} = 6\% \times e^{-0.15 \times 14} = 6\% \times e^{-2.1} \approx 6\% \times 0.122 \approx 0.73\%$
which is small enough that the observed effect at week 14 should be close to the true persistent effect $C$, letting the long-window confidence interval be read as a fair test of durability rather than a mix of fading novelty and true signal.

Trade-offs and pitfalls

• Waiting three half-lives before making the call costs real calendar time and delays every downstream decision riding on this experiment; for a low-stakes cosmetic change, teams often accept a shorter, less rigorous wait rather than the full 14 weeks in the worked example.
• The decay model assumes a single clean exponential; a novelty effect that itself varies by segment, a spike for new users layered with a slower-decaying resistance effect for long-tenured users, will not fit a single two-parameter curve well, and forcing the fit anyway can produce a confidently wrong half-life.
• Anchoring on exposure age rather than calendar date requires per-user first-exposure timestamps captured at assignment time; retrofitting this onto an experiment already running on calendar-date logging means exposure-age curves cannot be reconstructed after the fact.
• A pre-specified decision rule protects against motivated reasoning but is only as good as the pre-specified windows; if the true decay is much slower than assumed when the windows were chosen, day 91 may still be well inside the transient period, so a short pilot or a conservative overestimate of the likely half-life should inform window choice up front, not just the final analysis.