DoorDash Data Analyst Interview Preparation Guide - Entry Level

Direct answer

A good key performance indicator (KPI) is specific, tied to a clear business objective, computed from a documented, reliable data source, and paired with a target and a review cadence, so that when it moves, someone knows what to do. Leading KPIs predict an outcome early enough to act on it; lagging KPIs confirm what already happened. A KPI earns its place on a long-term dashboard only after it survives a validation check, not just because it sounded reasonable when proposed.

Structured elaboration

Validating that a KPI is reliable and worth keeping.

1. Document the exact formula, data source, and update cadence, and write down the assumptions so the definition is auditable later.
2. Check data quality: completeness, consistency, and where the numbers originate.
3. Back-test whether the leading KPI actually predicts the lagging outcome it's supposed to precede, using historical data (worked below), rather than assuming the relationship because it sounds logical.
4. Confirm actionability: does crossing a specific threshold map to a specific intervention, with a named owner and cadence? If nobody can say what they would do differently, the KPI is not ready, no matter how clean the data is.
5. Retire a KPI when it stops predicting the outcome it was chosen for, when no one has acted on it in several review cycles, or when its underlying data source becomes unreliable.

Worked example

Suppose, to illustrate the back-testing method, four months of paired data: this month's add-to-cart rate against next month's gross merchandise value.

Means: $\bar{x} = 9.5$, $\bar{y} = 227.5$.

Deviations from the mean: $x$: -1.5, -0.5, 0.5, 1.5; $y$: -27.5, -7.5, 7.5, 27.5.

$\sum (x-\bar{x})(y-\bar{y}) = (-1.5)(-27.5) + (-0.5)(-7.5) + (0.5)(7.5) + (1.5)(27.5) = 41.25+3.75+3.75+41.25 = 90$
$\sum (x-\bar{x})^2 = 2.25+0.25+0.25+2.25 = 5 \qquad \sum (y-\bar{y})^2 = 756.25+56.25+56.25+756.25 = 1625$
$r = \frac{90}{\sqrt{5 \times 1625}} = \frac{90}{\sqrt{8125}} \approx \frac{90}{90.14} \approx 0.998$

In this small illustrative dataset, add-to-cart rate correlates almost perfectly with next month's GMV, which is the kind of evidence (on real, noisier data, correlation well below 1 but still consistently positive across periods) that would justify keeping add-to-cart rate on a long-term dashboard rather than retiring it for a KPI that looked more intuitive but never actually predicted anything.

Trade-offs & pitfalls

A strong back-test correlation is evidence, not proof; a shared driver like a promotional calendar can move both the leading and lagging metric together without either causing the other, so the back-test should be revisited whenever the business context changes materially. Fitting the KPI choice too tightly to a short back-test window risks picking a metric that happened to correlate in that period by chance rather than one with a durable relationship. A lagging-only dashboard feels rigorous because it reports real outcomes, but by the time it moves it's too late to intervene, which is exactly the gap leading KPIs exist to fill; a healthy KPI set pairs at least one of each.

Direct answer

A Binomial$(n, p)$ distribution approximates a Poisson$(\lambda)$ distribution when $n$ is large, $p$ is small, and their product $\lambda = np$ stays moderate and roughly fixed as $n$ grows. Practically: $n$ in the hundreds or more, $p$ under about 0.05, with $np$ somewhere in the single digits to low tens works well; this is exactly the regime of "rare events counted over many independent opportunities," like defects per kilometer of cable or errors across many server requests.

Structured elaboration

The mathematical rule

Intuition for why: with $p$ small, the chance of two or more "successes" landing on the same trial-count window becomes negligible, so the combinatorial factor $\binom{n}{k}$ and the $(1-p)^{n-k}$ term simplify. In particular, $(1-p)^n \approx e^{-np} = e^{-\lambda}$ for small $p$, which is the Poisson kernel's leading term.

Practical thresholds

The mean check ($np$ moderate) is the most reliable single diagnostic, since $n$ and $p$ can each individually look "extreme" while their product is not in the rare-event regime.

Worked example

Rare server errors: 10,000 requests in an hour, each independently erroring with probability $p = 0.0003$.

Compare the probability of zero errors under each model:

import math
n, p = 10000, 0.0003
lam = n*p                      # 3.0 (up to floating-point noise)

p0_binom = (1-p)**n            # 0.04976466474747146
p0_pois = math.exp(-lam)       # 0.049787068367863965
abs(p0_binom - p0_pois)        # 2.24e-05

Both models give $\approx 0.0498$ for the probability of a clean hour, agreeing to four significant figures despite one requiring the exact binomial formula and the other only needing $\lambda = 3$. For an applied model of rare server errors or defect counts, this means you can drop the exact binomial machinery (which needs both $n$ and $p$ tracked separately) and work directly with the single-parameter Poisson$(\lambda)$, which is simpler to fit, simpler to reason about (mean = variance = $\lambda$), and simpler to compose across time windows (Poisson counts over disjoint intervals just add their $\lambda$'s).

Trade-offs & pitfalls

• The approximation breaks down when $p$ isn't actually small, even if $n$ is large - e.g. a coin-flip-like process with $p=0.4$ over 1000 trials is nowhere near Poisson-shaped regardless of how large $n$ is; check $p$, not just $n$.
• It also breaks down at small $n$ even with small $p$, if that makes $\lambda = np$ too small to be a meaningful count (e.g., $n=20, p=0.01 \to \lambda=0.2$) - the approximation quality depends on the full regime, not any single threshold in isolation.
• Real event counts are often overdispersed relative to Poisson. Poisson forces mean = variance; if observed variance is substantially larger than the mean (common when the underlying rate itself varies, e.g., error rates spike during incidents rather than staying constant), a negative binomial model fits better and a plain Poisson will understate uncertainty.
• Always validate numerically for decisions that matter, the way the worked example does above, rather than trusting the heuristic thresholds blindly - the thresholds are guidelines, not guarantees, and the actual approximation error is cheap to check directly.

Define the duplicate as "same entity and value, arriving within N minutes of each other" and detect it with a rolling comparison to the PREVIOUS row in the same partition, not a fixed time bucket, because a fixed bucket can miss duplicates that straddle a bucket boundary.

The bucket pitfall (verified)

A naive approach buckets each row into a fixed 5-minute wall-clock window and groups by `(user_id, amount, bucket)`. Two transactions 3 minutes apart, at 10:03 and 10:06, land in different fixed buckets (10:00-10:05 and 10:05-10:10) and are missed entirely, even though they are well within the 5-minute tolerance.

Correct rolling-tolerance form

```sql
WITH ordered AS (
SELECT *, LAG(occurred_at) OVER (PARTITION BY user_id, amount ORDER BY occurred_at) AS prev_ts
FROM txn
)
SELECT txn_id, occurred_at, prev_ts,
(prev_ts IS NOT NULL AND occurred_at - prev_ts <= INTERVAL '5 minutes') AS is_duplicate
FROM ordered ORDER BY txn_id;
```
`LAG` looks at the immediately preceding row for the same `(user_id, amount)`, so the gap is measured against the actual neighbor, not a wall-clock boundary.

Worked example (verified by execution)

For transactions at 10:03, 10:06, and 10:20 for the same user and amount: the fixed-bucket approach misses the 10:03/10:06 pair (different buckets). The LAG-based query correctly flags the 10:06 row as a duplicate of 10:03 (180-second gap, within tolerance) and correctly leaves the 10:20 row unflagged (840-second gap from its predecessor, outside tolerance).

Trade-offs and pitfalls

The rolling form is chained: if three transactions occur at 0, 3, and 6 minutes, each 3 minutes apart, only the second is compared to the first and the third to the second, so both are flagged as duplicates of their immediate neighbor even though the first and third are 6 minutes apart. Decide upfront whether that chaining behavior is the definition you want, or whether you need duplicates measured against the FIRST event in a cluster instead. When picking which row survives, keep the earliest arrival as canonical, since it is the one least likely to be the retried copy.

Direct answer. A segment should graduate from an ad-hoc, one-off cut to a canonical definition in the shared data model when it is reused often enough, and important enough, that maintaining a single, agreed-upon definition is worth more than the flexibility of letting each analyst redefine it locally. The decision framework weighs business impact, reusability, maintenance cost, and monitoring needs, and assigns clear ownership once a segment crosses that bar.

Structured elaboration.

• Business impact. A segment used to make or justify recurring, consequential decisions (which users get a retention campaign, how a KPI is reported to leadership) deserves a stable, auditable definition; a segment used once for a one-off exploratory question does not.
• Reusability across reports. If three different teams have each independently built their own version of "power user" with slightly different thresholds, that is a strong signal the segment should be canonicalized, both to save duplicated effort and to stop the definitions from silently drifting apart and producing inconsistent numbers in different reports.
• Maintenance cost and monitoring requirements. A canonical segment needs its definition version-controlled, its computation monitored for drift or breakage (an upstream schema change that silently changes who qualifies), and a documented process for updating the definition when the business reason for it changes; a segment not worth that ongoing investment should stay ad-hoc.
• Ownership and review cadence. Once a segment is canonicalized, assign a single owner (typically the team most affected by decisions that use it) responsible for approving definition changes, and set a review cadence, commonly aligned with major planning cycles, to check the definition still reflects current business reality rather than assumptions from when it was first defined.

Worked example. A "power user" definition that started as one analyst's ad-hoc query for a single deck, but is now referenced by the growth team's dashboard, the lifecycle-marketing team's campaign targeting, and a quarterly business review, has crossed the bar: it is reused across multiple consequential decisions, and the cost of three teams silently disagreeing about who counts as a power user (because each copied and slightly modified the original query) is high enough to justify canonicalizing it, documenting the exact criteria, assigning an owner, and replacing the ad-hoc copies with references to the single definition.

Trade-offs and pitfalls. Canonicalizing too aggressively creates governance overhead for segments nobody actually reuses, slowing down exploratory analysis for no real benefit. Canonicalizing too late lets inconsistent, silently-diverging definitions of the same conceptual segment accumulate across teams, which is far more expensive to untangle later (reconciling years of reports built on different "power user" thresholds) than it would have been to formalize the definition the first time a second team asked to reuse it.

Direct answer
Identify which distinct audiences need to know, choose the channel and level of detail each one actually needs, and sequence the communication so people closer to the change (or who need to prepare others) hear it before the broader audience does.

Structured elaboration

1. Segment the audiences. A single announcement rarely fits everyone; separate, for example, the people directly affected day-to-day, the managers who'll field questions from their teams, and anyone who needs advance notice to prepare (support, a partner team, external users).
2. Match channel to audience and stakes. A high-stakes or sensitive change might warrant a live meeting or a call for the most affected group, supplemented by a written announcement for broader reach and future reference; a low-stakes change might only need the written version.
3. Sequence deliberately. People who need to answer questions from others (managers, support) generally need to hear it before the people who'll be asking them those questions; announcing to everyone simultaneously can leave the people expected to explain it caught flat-footed.
4. Decide what each audience actually needs to know, not just a single message copy-pasted everywhere; a technical team needs the mechanism, an executive audience needs the business impact, and end users need what changes for them specifically.
5. Plan for questions. Include a channel or contact for follow-up questions, and consider pre-briefing a few likely questions so the people fielding them aren't caught off guard.

Worked example
Rolling out mandatory two-factor authentication for all employee accounts: first, brief IT support and team leads a few days ahead with the exact rollout date, the reason, and answers to likely questions, since they'll field employee questions once it's public. Then send the broad announcement to all employees with the what and why in plain language, the exact date it takes effect, and a link to a short setup guide, plus a support contact for anyone who gets stuck. A separate, more detailed technical note goes to the security and IT teams covering enforcement mechanism and rollback plan, which the general employee announcement doesn't need.

Trade-offs and pitfalls

• Announcing to the broadest audience first, before briefing the people who'll need to answer questions, is a common sequencing mistake that leaves support and managers unprepared.
• One-size-fits-all messaging either overwhelms a general audience with irrelevant technical detail or underserves a technical audience that needed the mechanism, not just the headline.
• Too many channels for a low-stakes change can feel like overkill and train people to tune out future announcements; match the weight of the communication plan to the actual stakes of the change.

Single headline (15–20s): "Conversion on the checkout page dropped 18% last month, costing an estimated $420K in lost revenue."

Two supporting data points (60–90s):

• "Daily conversion rate fell from 2.8% to 2.3% after the 3rd week of March — a relative decline of 18% (p<0.01)."
• "Abandonment spiked on step 2 of checkout: 42% of sessions drop there vs. 27% baseline — average session time on that step increased 35%."

Quick context (60s):

• "This dashboard pulls from web analytics and orders table; no major traffic or promo changes occurred in March. The timing aligns with a UI release on March 18th."

One recommended action (30–45s):

• "Roll back the March 18th checkout UI change to a feature flag, run an A/B test comparing old vs. new, and prioritize quick fixes for step 2 (form validation and load time). Expected outcome: recover at least half the decline within two weeks, recouping ~$210K."

Why this order:

• Start with the headline to grab executive attention and state impact (money). Use two succinct data points to prove the claim and show where the problem is. Add minimal context to rule out confounders. Finish with a single, measurable action so the executive can approve next steps immediately.

A cohort-based root-cause approach to a retention decline works by isolating whether the drop is a real, uniform product problem or concentrated in a specific slice of users, which changes the fix entirely.

Defining the cohorts

Define cohorts by onboarding month over the last six months (the population described in the question), so each cohort's retention curve is comparable at the same days-since-onboarding, rather than comparing raw calendar-time retention across cohorts that started at different points in their own lifecycle.

Comparative metrics to compute

• Retention curve per monthly cohort, to see whether the decline is concentrated in the most recent cohorts (suggesting something changed recently, like a product regression or a shift in acquisition quality) or is spread evenly across all six months (suggesting a longer-running, structural issue).
• Retention broken out by acquisition channel within each cohort, since a channel-mix shift (more low-intent users from a new paid channel, for example) can look like a retention decline when it's really a composition change.
• Retention broken out by platform/device, to rule out a technical regression specific to one platform.

Confounding factors to watch for

• Acquisition-channel mix shifts: if a cheaper but lower-intent channel grew as a share of signups over the period, average retention will fall even if EVERY individual channel's retention is unchanged, a classic Simpson's-paradox-style trap.
• Seasonality: if the six-month window spans a seasonal dip (a post-holiday lull, for example), part of the decline may be a normal yearly pattern rather than a genuine regression.
• Instrumentation changes: verify that the definition of 'active' (the retention numerator) hasn't quietly changed partway through the period, which would make the cohorts artificially incomparable.

Trade-offs and pitfalls

Jumping to a product-change explanation before ruling out channel-mix shifts and seasonality is the most common analytical mistake here; segment first, hypothesize second.

Direct answer

merge()'s how= parameter controls which rows survive when two DataFrames are joined on a key: inner keeps only keys present on both sides, left keeps every row from the left DataFrame regardless of a match, right keeps every row from the right DataFrame regardless of a match, and outer keeps every key from either side, filling with NaN wherever the other side has no match. indicator=True adds a _merge column showing whether each result row came from "left_only", "right_only", or "both", which is the fastest way to see exactly which rows failed to match on either side.

The four join types, demonstrated

import pandas as pd

left = pd.DataFrame({
    "id": [1, 2, 2, 3],
    "left_val": ["A", "B", "C", "D"],
})
right = pd.DataFrame({
    "id": [2, 2, 4],
    "right_val": ["X", "Y", "Z"],
})

for how in ["inner", "left", "right", "outer"]:
    result = pd.merge(left, right, on="id", how=how, indicator=True)
    print(f"--- {how} ({len(result)} rows) ---")
    print(result)

Verified row counts on pandas 3.0.3: inner produces 4 rows, left produces 6, right produces 5, outer produces 7. Walking through why:

• inner (4 rows): only id=2 exists on both sides, and since it appears twice on the left and twice on the right, every left/right pairing for that key is produced, 2 x 2 = 4 rows, none of which has a NaN in either left_val or right_val.
• left (6 rows): the same 4 matched id=2 rows, plus id=1 and id=3 (present only on the left) each appearing once with right_val as NaN and _merge == "left_only".
• right (5 rows): the same 4 matched id=2 rows, plus id=4 (present only on the right) with left_val as NaN and _merge == "right_only".
• outer (7 rows): the union, the 4 matched rows, plus id=1, id=3 as "left_only", plus id=4 as "right_only".

Why merges can unintentionally explode: duplicate keys

If either side has a key that appears more than once, merge() produces every combination of matching rows for that key, a Cartesian product on the duplicated portion, not a simple row-for-row pairing. In the example above, id=2 appears twice on the left (left_val = B and C) and twice on the right (right_val = X and Y), so the inner join alone produces 2 x 2 = 4 rows just for id=2, four combinations (B-X, B-Y, C-X, C-Y) where you might have expected two. On real data, where a key that should be unique (an order id, a user id) accidentally has duplicates, often from an upstream bug or an unintended many-to-many relationship, this silently multiplies row counts and downstream aggregates (sums, counts) become inflated in a way that is easy to miss unless you are specifically checking for it, the merge itself does not raise an error.

Detecting and preventing key-duplication explosions

# check for duplicate keys before merging
left["id"].duplicated().any()      # True here, id=2 appears twice
right["id"].duplicated().any()     # True here, id=2 appears twice

# see exactly which keys are duplicated and how many times
left.groupby("id").size().loc[lambda s: s > 1]

# make pandas itself raise if the join isn't the cardinality you expect
pd.merge(left, right, on="id", how="left", validate="many_to_one")
# raises MergeError here, because id=2 is NOT unique on the right side

validate= ("one_to_one", "one_to_many", "many_to_one", "many_to_many") is the most reliable check because it does not depend on remembering to look, it fails loudly at merge time if your assumption about key uniqueness on either side turns out to be wrong.

Anti-join: rows that exist on only one side

indicator=True combined with how='outer' also gives you the anti-join pattern directly: filter the merged result down to only the rows that failed to match, using the same _merge column already shown above.

merged = pd.merge(left, right, on="id", how="outer", indicator=True)
left_only  = merged[merged["_merge"] == "left_only"]   # rows in `left` with no match in `right`
right_only = merged[merged["_merge"] == "right_only"]  # rows in `right` with no match in `left`

Verified on the same fixture as above: left_only returns id=1 and id=3 (present only on the left), right_only returns id=4 (present only on the right). This is the standard way to answer "which rows in one table have no counterpart in the other," for example finding orders with no matching payment record, or customers with no matching order, without pulling in every matched row you don't care about.

Trade-offs and pitfalls

• indicator=True is cheap and gives immediate visibility into match rates, but it adds a categorical _merge column to the result that you need to drop before downstream code that is not expecting it (result.drop(columns="_merge")), or filter on before further processing (result[result["_merge"] == "both"] to keep only matched rows explicitly).
• outer merges are the easiest to reason about for "did I lose anything," since nothing from either side disappears, but they are also the easiest to accidentally ship with unintended NaNs propagating into downstream numeric operations if you forget that unmatched rows exist at all.
• Deduplicating with drop_duplicates(subset=["id"]) before merging is a real fix for the explosion problem, but only when duplicates are genuinely redundant; if the duplicate rows carry different, meaningful information (as left_val = B and C do for id=2 here), dropping one silently discards real data rather than fixing a bug, decide which case you are in before reaching for drop_duplicates as the fix.
• validate= catches the problem at merge time, which is strictly better than discovering it downstream via an inflated sum() or count(), but it requires you to actually know and state the cardinality you expect, which is itself a modeling decision worth making explicit in code rather than assuming.

Direct answer

One practical way to detect early product-market fit signals is to look at 30-day retention within acquisition-week cohorts: if a meaningful and growing share of each new cohort is still active a month later, and that share holds up or improves as more cohorts are observed, that is a reasonable early heuristic that the product is delivering repeatable value rather than a one-time novelty.

Structured elaboration

The cohort dimension to use is acquisition week, because it lets you compare successive groups of new users on equal footing (same amount of elapsed time since joining) rather than comparing an aggregate metric that mixes users at very different points in their lifecycle. The metric to pair with it is either 30-day retention or the percentage of a cohort completing the product's core action at least once in a defined follow-up window, whichever better reflects genuine repeat value for that specific product.

A simple threshold heuristic: if 30-day retention for successive weekly cohorts is trending upward, or at minimum holding flat above a level the team considers meaningfully better than a typical unengaged baseline for the category, that is treated as an early positive signal. The threshold itself is necessarily product-specific (a reasonable bar for a daily habit product looks nothing like a reasonable bar for an infrequently-used utility), so a team usually calibrates it against comparable products in the same category rather than a universal number.

Worked example

Suppose a new note-taking app tracks 30-day retention for its first six weekly signup cohorts: 8%, 11%, 14%, 13%, 17%, and 19%. Even though each individual number is modest in isolation, the upward trend across six consecutive cohorts, rather than a flat or declining line, is itself informative: it suggests something about the product or its onboarding is genuinely improving cohort quality over time, which is a stronger early signal than any single cohort's absolute retention number. By contrast, six cohorts showing 15%, 12%, 16%, 11%, 14%, 13%, hovering with no clear trend, would be a weaker signal even at a similar average level, since it looks more like noise around a stable (and possibly weak) baseline than evidence of improving fit.

Trade-offs and pitfalls

Early cohorts are small by definition, so a trend across only a handful of weekly cohorts can be noisy; treating six data points as a confirmed trend rather than a suggestive early read risks over-claiming certainty the sample size does not support. It is also easy to conflate a genuinely improving product with an improving ACQUISITION mix (later cohorts skewing toward higher-intent users because of a change in where signups are coming from), so a careful read checks whether the acquisition channel mix has stayed roughly constant across the cohorts being compared before crediting the product itself for the trend.

DISTINCT deduplicates whole rows (or whole selected column sets); it can't compute anything, which is exactly where GROUP BY with an aggregate becomes necessary rather than optional.

Structured elaboration

"What is the difference between GROUP BY and DISTINCT" has a simple case where they overlap: for a plain single-column distinct list with no aggregate involved, SELECT DISTINCT category FROM sales and SELECT category FROM sales GROUP BY category return the identical set of rows. For example, given categories 'electronics', 'toys', 'electronics', both return exactly the two rows 'electronics' and 'toys', with no computed value attached to either. And there's a case where they clearly don't overlap: any time you need a computed value per group, not just the group's identity. SELECT DISTINCT category FROM sales and SELECT category, COUNT(*) FROM sales GROUP BY category both group the same way internally, but only the second one can attach a count, sum, or average to each category. There is no DISTINCT-based way to also report "how many sales rows are in each category" without introducing GROUP BY (or an equivalent subquery/window function) somewhere.

Worked example

Wanting "each distinct product category, and how many products are in it" requires GROUP BY: SELECT category, COUNT(*) AS n FROM products GROUP BY category. SELECT DISTINCT category, COUNT(*) isn't valid syntax in most engines when mixing DISTINCT with an aggregate this way, and even where it parses, it doesn't mean what you'd want.

Trade-offs and pitfalls

A quick test for which tool fits: if the question has the word "how many" or any other aggregate verb (total, average, most recent) attached to each group, GROUP BY is required; if it's purely "list the unique values of X", DISTINCT is suf ficient and simpler.