DoorDash Data Scientist Interview Preparation Guide (Entry Level)

Direct answer

A communication about a recurring data-quality issue to executive stakeholders needs a plain-language problem statement, the magnitude of impact, a root-cause summary, a remediation plan with timelines and named owners, and the residual risk that remains after the fix, deliberately leaving out implementation-level technical detail that does not change the decision the executive audience needs to make.

Structured elaboration

• Problem statement: one or two sentences, in business terms, no jargon, stating what happened and what it affects.
• Magnitude: a specific, quantified number (dollars, percentage, duration), not a vague qualifier like "significant," since a specific number is what lets an executive calibrate how much attention this genuinely deserves relative to everything else competing for their time.
• Root-cause summary: enough detail to establish that the cause is understood and the fix is targeted at the real problem, not a full technical post-mortem; the goal is to build confidence that this is being handled competently, not to teach the audience the underlying engineering.
• Remediation plan: concrete dates and named owners, not "we're working on it," since vague timelines are what erode confidence fastest with an executive audience.
• Residual risk: explicitly state what will NOT be fully resolved by this fix, and why, rather than implying the problem is entirely closed; an executive who later discovers an unmentioned residual risk on their own loses more trust than one who was told about it up front.

Worked example

"We identified a recurring issue in [pipeline] that has been undercounting [metric] by approximately 3% since [date], affecting [specific reports/decisions]. Root cause: [one-sentence summary]. We are deploying a fix by [date], owned by [name/team], and will backfill corrected historical figures by [date]. Residual risk: this fix addresses the specific bug found, but the underlying pipeline lacks automated regression testing for this class of error; we recommend a follow-up investment of [scope] to close that gap and prevent a similar issue recurring in a different form." This gives the executive everything needed to decide whether they are satisfied with the response or want to push for the follow-up investment, without requiring them to understand the technical root cause in detail.

Trade-offs and pitfalls

The instinct to lead with reassurance ("it's fixed, don't worry") rather than with the honest magnitude and residual risk is the most common way this kind of communication backfires: if a related issue resurfaces later, or if the residual risk that was omitted turns out to matter, the credibility cost of appearing to have understated the problem the first time is far higher than the short-term discomfort of stating it plainly up front.

Direct answer

Go to the colleague privately first, before doing anything more public, and frame the concern as a question about the sampling method rather than a conclusion about their competence. Bring the specific evidence, propose a joint, falsifiable check that would settle whether the bias is real, and only then decide together how to handle the already-circulated report.

Structured elaboration

1. Verify before you raise it. Confirm the specific gap yourself (which source, what kind of gap) so you are not escalating a hunch. Raising a vague suspicion is more likely to read as an attack than raising a concrete, checkable one.
2. Private channel first. Do not raise it in the stakeholder meeting or a public thread. The goal at this stage is a shared understanding between the two of you, not a public correction.
3. Lead with evidence, not the conclusion. Ask how the sample was chosen and show what you noticed, rather than opening with "your report is biased." The evidence does the work; you are not the one delivering a verdict.
4. Propose a joint, falsifiable test. Agree in advance on a specific check that would settle the question either way, for example, re-running the analysis with a more complete data source and comparing results. If the two produce materially different conclusions, that is evidence of the bias; if not, the original report holds and nothing was lost.
5. Handle the stakeholder-facing correction together. If the test confirms the bias, present the fix as a normal part of the quality process, credit the colleague's original work, and avoid framing it as catching an error.

Worked example

A colleague circulated a cohort analysis to stakeholders built from a single data source you know has intermittent collection gaps. Rather than flagging it in the stakeholder thread, you ask to talk privately: "I noticed this cohort uses source A, do you know if that source had full coverage this quarter?" You show the specific evidence (gap periods, affected date ranges) and ask how the sample was chosen. Together you agree on the joint test: re-run the same cohort analysis using a second, more complete source and compare the two results. If the numbers move meaningfully, you have confirmed a real bias and both go to stakeholders together with an updated report and a data-quality caveat; if the numbers hold steady, the original report stands and the check cost an afternoon, not a reputation.

Trade-offs & pitfalls

• Raising it directly in the stakeholder meeting "to protect the org from a bad decision" scores a point in the moment but damages the working relationship and makes the colleague defensive on the next collaboration.
• Staying silent because raising it feels confrontational lets a real bias ship into decisions uncorrected, which is a worse outcome for the partnership than a slightly awkward private conversation.
• The senior move here is designing the joint test so the evidence settles the question, rather than relying on how persuasively you phrase the concern. A well-chosen test does the convincing; the conversation itself does not have to.
• A remaining pitfall: proposing a fix without proposing how to verify it worked. A joint investigation that ends without a joint, agreed check on the outcome tends to resurface as the same disagreement later.

Situation: Product team measures success by conversion rate (short-term), while Customer Success focuses on long-term retention — both valid but potentially conflicting goals. As the data scientist, I’d create a shared, evidence-based framework that quantifies trade-offs and enables data-driven decisions.

Metric set:

• Short-term: Day-0 to Day-7 conversion rate, checkout/activation rate, conversion funnel drop-offs.
• Long-term: 30/60/90-day retention, churn rate, cohort survival curve, and Net Revenue Retention (NRR).
• Intermediate leading indicators: 7–30 day engagement (weekly active days, key feature usage).
• Economic KPIs: 30/90-day incremental LTV, CAC payback period.
• Guardrails: error rates, support contacts, and quality metrics to catch negative customer experiences.

Experiment strategy:

• Run randomized A/B tests or factorial experiments exposing users to Product’s variant, CS-favored variant, and a hybrid.
• Stratify by acquisition channel and user persona; use blocking to balance covariates.
• Choose sample sizes powered for both conversion lift (short horizon) and a minimum detectable effect on retention; if retention power is infeasible, use surrogate outcomes + longer rolling experiments.
• Use phased rollouts (ramp to 100%) with a long-term holdout cohort retained to measure downstream effects.

Analysis plan:

• Primary: estimate causal effects on short-term conversion (difference-in-proportions or logistic regression with covariate adjustment) and on retention (Kaplan–Meier + Cox models; survival analysis).
• Compute incremental LTV by treatment using uplift modeling or causal inference (IPW/ATE) to translate engagement→revenue.
• Heterogeneity: segment treatment effects by persona/channel to surface where trade-offs exist.
• Mediation: test whether short-term conversion gains are mediated by reduced early engagement leading to lower retention.
• Decision rules: present Pareto frontier of conversion vs. retention vs. LTV; recommend choices that maximize long-term value or meet constrained objectives (e.g., minimum retention floor).
• Visuals: cohort survival plots, funnel conversion charts, incremental LTV curves, and heatmaps of heterogeneous effects.
• Statistical rigor: pre-registration, multiple testing correction, and replication on holdout windows.

Outcome & alignment:

• Deliver a dashboard for stakeholders showing short- and long-term impacts and trade-offs, plus recommended policies (e.g., adopt conversion changes only for segments where LTV↑ or within acceptable retention loss).
• Run weekly reviews early in rollout and a deep analysis after 90 days; iterate on product/CS compromise informed by data.

This approach makes trade-offs explicit, uses rigorous experimentation and causal analysis, and aligns teams by translating both conversion and retention into shared economic outcomes.

The two adoption numbers together tell a very different story than either alone: a healthy top-line adoption rate can still mask a small, weak core of repeat users, and that gap is exactly what a power-user rate is designed to surface.

Worked calculation

Given 2,000 eligible users, 500 used QuickShare at least once, and 150 used it three or more times within 14 days:
$\text{14-day adoption rate} = \frac{500}{2{,}000} = 25\%$
$\text{14-day power-user adoption rate} = \frac{150}{2{,}000} = 7.5\%$

What the two numbers imply together

Of the 500 users who tried the feature at least once, only 150 (30% of the ones who tried it, $150/500$) came back for three or more uses; the other 70% of first-time triers ($350/500$) did not return to it a third time within the window. A quarter of the eligible population tried the feature (a respectable initial discovery rate), but only about 1 in 13 eligible users ($150/2{,}000$) turned it into a repeated habit, which is the number that actually predicts whether QuickShare is becoming a durable part of the product rather than a novelty that gets tried once and abandoned.

Trade-offs and pitfalls

Reporting only the 25% headline adoption number would look like a solid early result and could lead a team to declare success prematurely; the much lower 7.5% power-user rate is the more honest signal of whether the feature is delivering repeat value, and it's the number that should drive a keep/iterate/deprioritize decision, not the top-line figure alone.

Direct answer
A data-splitting policy fixed and versioned per project (train/validation/test, with a held-out test touched rarely), a default search strategy (random or Bayesian depending on trial-budget and model cost), an explicit promotion gate from experimentation to champion (a defined metric bar plus a human sign-off, not an automatic swap), and full experiment tracking (configuration, code version, data version, metrics) as the backbone of both reproducibility and audit.

Structured elaboration

• Data splitting: define the split policy once per project (e.g. time-based for anything with temporal structure, stratified random otherwise), version it so everyone on the team uses the identical split, and treat the test set as precious, touched only for a final, occasional check, never as a routine part of iteration.
• Default search strategy: random search as the safe default for small trial budgets or cheap models; Bayesian optimization for expensive models with a modest hyperparameter count; multi-fidelity (Hyperband/ASHA, Asynchronous Successive Halving) when trials can be cheaply partially evaluated. The team shouldn't have to re-decide this from scratch on every project, a documented default with clear exceptions saves real time.
• Promotion from experimentation to champion: a defined metric bar the candidate must clear (not just "better than current champion" by any margin, but by a margin that clears your noise threshold, tying back to the statistical-significance discussion), plus a human review step before a new champion actually replaces the current production model, since automated promotion on a noisy metric alone is a real risk.
• Reproducibility and audit at scale: every experiment run tracked with its full configuration, code version (commit hash), data version, and resulting metrics in a shared, queryable system; as headcount grows, this is what lets someone NOT involved in the original experiment understand what was tried and why a given model was promoted, rather than that knowledge living only in one person's memory or a Slack thread.

Worked example
A team of 15 data scientists shares one experiment-tracking backend; every training run auto-logs its config/code-version/data-version/metrics; promotion to champion requires clearing a pre-agreed significance-tested improvement AND a sign-off from a designated reviewer, both enforced by the pipeline rather than left to individual discipline, so the process holds up even as new team members join who weren't around when the conventions were set.

Trade-offs & pitfalls
The single most common failure mode as a team scales past a handful of people is exactly the ad-hoc version of this: everyone using slightly different splits, no shared tracking, and promotion decisions made informally; the fix isn't more process for its own sake, it's making the RIGHT defaults easy and the wrong shortcuts hard, e.g. tooling that auto-logs everything rather than relying on individual discipline to remember to do it.

Approach: use Spark window functions partitioned by user_id and ordered by event timestamp, using a range-based window covering the previous 6 days + current day (7-day window). Cast timestamps to long (seconds) because rangeBetween accepts orderable numeric. Repartition by user_id (or hash) to localize data and reduce shuffles, tune shuffle partitions, and persist intermediate frames when reused.

from pyspark.sql import functions as F
from pyspark.sql import Window

# df: (user_id STRING, event_ts TIMESTAMP, value DOUBLE)
# 7 days in seconds
SEVEN_DAYS = 7 * 24 * 3600
# Convert timestamp to epoch seconds for range window
ts_col = F.col("event_ts").cast("long")

# Optional: repartition to co-locate user data (reduce shuffle during windowing)
# Choose num_partitions based on cluster size and cardinality of user_id
df_repart = df.repartition(200, "user_id")  # tune 200 -> spark.executor.cores * executors

w = (
    Window
    .partitionBy("user_id")
    .orderBy(ts_col)
    .rangeBetween(-SEVEN_DAYS + 1, 0)  # previous 6 days + current day inclusive
)

result = (
    df_repart
    .withColumn("value_7d_avg", F.avg(F.col("value")).over(w))
    .select("user_id", "event_ts", "value", "value_7d_avg")
)

Key points / reasoning:

• Use rangeBetween on epoch seconds to get time-based rolling windows (rowsBetween would use row counts).
• Repartition by user_id before the window to minimize full-cluster shuffles; pick partitions ≈ executors * cores.
• Tune spark.sql.shuffle.partitions to match cluster size and avoid many small files/tasks.
• Persist df_repart if reused.

Memory & performance considerations:

• Window operations can be memory-heavy per partition; ensure partition sizes are moderate (aim for 100MB–1GB per task).
• Handle skew: if some user_ids dominate, salting or splitting hot keys avoids single huge partitions.
• Use map-side aggregation patterns where possible; avoid wide joins before windows.
• Increase executor memory or enable Tungsten sort optimizations; monitor spill-to-disk (spark.memory.offHeap/settings) and adjust shuffle.compress/spark.shuffle.spill.compress.
• For extremely large data, consider approximate rolling aggregates (Sketches) or pre-aggregating by day then doing a 7-day rolling over days (reduces rows by factor of events/day).

Edge cases:

• Null timestamps/values: filter or define behavior.
• Irregular event frequency: range window handles missing days naturally.
• Late data: decide watermarking strategy before aggregation if streaming.

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.

Direct answer: Cold-start entities (a brand-new user or item with little or no history) need an explicit fallback strategy rather than simply feeding missing or zero-filled features into the model, because the absence of history is itself informative and needs to be represented, not disguised as a normal (if low) value.

Structured elaboration:
Common strategies: cohort-level defaults (fall back to the average behavior of a similar segment, e.g. new users from the same acquisition channel, rather than a global average or a naive zero); explicit missingness flags (a boolean "is this entity new" feature, so the model can learn a genuinely different behavior for the cold-start case rather than being misled by a filled-in value that looks like real history); synthesized or content-based features (for a new item with no interaction history, using its metadata, category, or a similarity to existing items instead of behavioral signal that doesn't exist yet); and transfer or pretrained representations (an item embedding warm-started from content similarity to existing items, refined as real interaction data accumulates).

For a rapidly-changing catalog with almost no historical interaction data (a brand-new product vertical), the practical approach usually leans harder toward content-based and cohort-based features initially, with a defined transition plan for when enough real interaction data accumulates to shift weight toward behavioral features, rather than trying to force behavioral features to work from day one with almost no signal behind them.

Worked example: A recommendation model serving a brand-new item defaults its "average rating" feature to a global constant. Without an explicit cold-start flag, the model treats this constant as if it were a genuinely-observed, middling rating, likely under- or over-recommending the item based on an artifact of the fallback value rather than any real signal; adding an explicit "is new item" flag lets the model instead learn to weight content-based signals more heavily specifically in the cold-start case, producing meaningfully different (and more sensible) behavior for new items than old ones.

Trade-offs and pitfalls: The complexity-versus-uplift trade-off is real: building a sophisticated transfer-learning cold-start system is a meaningful engineering investment, and for a product where cold-start entities are rare or low-stakes, a simpler cohort-default-plus-flag approach may capture most of the practical benefit at a fraction of the cost.

Direct answer

LAG(value, 365) assumes the row exactly 365 positions back is "the same calendar date one year ago." That assumption only holds if every day has exactly one row and no leap day falls inside the twelve months between the two rows; once a February 29 sits in that span, the 365-row offset lands one calendar day early. The fix is to stop counting rows and instead join the table to itself on date - INTERVAL '1 year', which tracks the calendar directly. A second, independent problem is that "the same calendar date last year" is not "the same day of the week": a Monday this year usually is not a Monday on the same numeric date last year, which matters for anything with weekly seasonality (retail traffic, weekday-vs-weekend patterns). Fixing that requires aligning on the ISO week (the ISO 8601 standard's week-numbering scheme, where every week runs Monday through Sunday) and weekday, not on the calendar date.

Structured elaboration

Why the row offset breaks: LAG(x, 365) is positional, not date-aware. Executed directly: DATE '2024-03-01' - INTERVAL 365 DAY returns 2023-03-02, one day later than the true "same date last year" (2023-03-01), because 2024 is a leap year and the twelve months between those two dates contain 366 days, not 365. DATE '2024-03-01' - INTERVAL 1 YEAR correctly returns 2023-03-01 because interval-year arithmetic follows the calendar, not a fixed day count.

Fix 1, calendar-date join:

SELECT
  cur.store_id, cur.sale_date, cur.total_sales,
  prev.total_sales AS total_sales_last_year,
  CASE WHEN prev.total_sales IS NULL THEN NULL
       ELSE ROUND((cur.total_sales - prev.total_sales)::numeric / prev.total_sales * 100, 2)
  END AS pct_change_yoy
FROM daily_sales cur
LEFT JOIN daily_sales prev
  ON prev.store_id = cur.store_id
 AND prev.sale_date = cur.sale_date - INTERVAL '1 year';

February 29 has no "same calendar date" last year at all; decide explicitly whether it maps to February 28 or March 1 in the join (a CASE on the anchor date), and document the choice, because either is defensible and silent inconsistency between reports is worse than either choice alone.

Fix 2, weekday alignment: two workable techniques, with different trade-offs.

• A fixed 364-day (52-week) offset guarantees an exact day-of-week match, because 364 = 52 × 7. Executed: DATE '2024-03-04' - INTERVAL 364 DAY returns 2023-03-06, and both 2024-03-04 and 2023-03-06 are Mondays. The cost is that 364 days is not a full calendar year, so across several years the "last year" comparison date drifts away from the true anniversary date by roughly one to two days per year.
• An exact join on (ISO year - 1, ISO week, ISO weekday) anchors to the actual week structure instead of a fixed day count. Executed against two rows (2023-03-06, a Monday in ISO week 10 of 2023; 2024-03-04, a Monday in ISO week 10 of 2024): joining on isoyear(prev) = isoyear(cur) - 1 AND weekofyear(prev) = weekofyear(cur) AND isodow(prev) = isodow(cur) correctly matches the two Mondays.

Worked example

Naive calendar-date weekday check: 2024-03-04 is a Monday; the naive "same date last year," 2024-03-04 - INTERVAL 1 YEAR = 2023-03-04, is a Saturday. A week-over-week or day-of-week-sensitive comparison using the naive join would be comparing a Monday's traffic to a Saturday's traffic and drawing a conclusion about "year-over-year growth" that is really a day-of-week artifact.

Trade-offs & pitfalls

• The fixed-365-row offset is the cheapest to write and looks correct on data that happens not to cross a leap day during testing, which is exactly how this bug ships silently.
• The calendar-date self-join needs an index on (store_id, sale_date) to stay cheap; without one, the self-join becomes an expensive full scan on both sides.
• The 364-day weekday-alignment offset is simple but not exact over multiple years; if you need the comparison to stay a true anniversary AND stay on the same weekday indefinitely, only the ISO year/week/weekday join does both correctly.
• ISO week numbering follows the Gregorian calendar's own week structure; a business running a genuinely different fiscal calendar (e.g. 4-4-5 retail calendars) needs to join on that calendar's own week definition, not ISO weeks, or the "same week" comparison is still wrong despite looking fixed.

Structure (15 minutes)

• 0:00–1:00 — Purpose & agenda: “I have 15 minutes. Goal: get 1–2 actionable items I can apply in the next two weeks. Does that work?”
• 1:00–8:00 — Focused questions (deep dive on one topic)
• 8:00–12:00 — Clarify expectations and metrics for success
• 12:00–14:00 — Agree on concrete next steps
• 14:00–15:00 — Quick recap & scheduling follow-up

Specific questions (pick 2–3)

• “Which one area of my recent work would give the most impact if I improved it in the next two weeks — model quality, reproducibility, stakeholder communication, or experiment speed?”
• If model quality: “What specific metric or failure mode should I target first (e.g., AUC lift on holdout, calibration, bias on segment X)?”
• If communication: “What change in my deliverable would make it clearer for stakeholders — different visuals, an executive summary, or reframing recommendations?”
• “What’s the smallest experiment or task I can complete in two weeks to demonstrate progress?”
• “How will you judge improvement? What evidence would make you say ‘that worked’?”

Converting feedback into prioritized, trackable steps

1. Turn feedback into 1–3 SMART tasks with acceptance criteria (example: “Improve model calibration for segment X: reduce Brier score from .18 to <.12 on validation within two weeks; add calibration plot & short note”).
2. Prioritize using impact × effort (ICE): Impact (business value), Confidence, Effort (time). Score and pick top 1–2.
3. Create tickets (Jira/GitHub) with owner, due date, tests, & required review. Link to experiment branch.
4. Share plan with manager via 1-line Slack + ticket link; request a 10-min follow-up in two weeks to review evidence.
5. Track progress daily with a short checklist and attach artifacts (plots, PRs, meeting notes) so the follow-up is evidence-based.

Example (data-science)

• Feedback: “Improve model explainability for ops team.”
• Task: “Add SHAP summary + one-pager mapping top 5 features to operational levers; demo in next ops sync.” — Ticket created, ICE score high, due in 10 days.

Phrasing tips

• Ask for specifics (“how would you measure?”), time-box requests, confirm acceptance criteria, and end by scheduling the follow-up.