DoorDash Data Analyst Interview Preparation Guide - Staff Level

Customer Lifetime Value (LTV) and Customer Acquisition Cost (CAC) are core metrics for judging which markets to prioritize.

Definitions and simple formulas

• CAC = Total acquisition spend in period / Number of new customers acquired in that period.
• Simple LTV (cohort-based) = Average revenue per customer per period × Average customer lifetime (in periods). Or using margin:
  LTV = (Average revenue per period × Gross margin %) × Average lifetime (periods).

How to compute from transaction & acquisition data (simple approach)

1. From acquisition data (marketing/spend, signup timestamps) compute CAC per market: sum(marketing_spend where acquisition_market = M) ÷ count(new_customers where acquisition_market = M).
2. From transaction data compute per-customer revenue series for the cohort (e.g., customers acquired in Q1):
   • avg_revenue_per_customer_per_month = total_revenue_from_cohort / number_of_customers / months_tracked.
   • estimate average lifetime by measuring retention curve (e.g., mean months until churn) or use 1 / churn_rate.
   • plug into LTV formula (optionally apply gross margin).

Key business assumptions that most affect comparability between markets

• Average gross margin by market (pricing, cost differences).
• Customer lifetime / churn behavior (cultural usage, competition).
• Attribution window and marketing channel mix (multi-touch attribution vs. last-click).

Three caveats when using LTV/CAC to prioritize markets

1. LTV estimates depend heavily on limited historical data — early markets or short windows over/underestimate lifetime. Use conservative ranges and sensitivity analysis.
2. CAC varies by channel mix and scale; extrapolating current CAC assumes similar spend efficiency as you scale, which may not hold.
3. Currency, unit economics, and operating costs differ by market (taxes, fulfillment); comparing raw LTV/CAC without normalizing to margin and local costs can be misleading.

Recommendation: compute cohort LTVs, normalize by gross margin, run sensitivity tests on lifetime and CAC, and present LTV:CAC ratio plus payback period to stakeholders for market prioritization.

I would first separate disagreement on the outcome from disagreement on the method. Then I would bring the executives into a short decision session with a one-page brief: the business goal, the options, the trade-offs, and the decision needed. I would make decision rights explicit using RACI, which means Responsible, Accountable, Consulted, and Informed. That way, everyone knows who recommends, who decides, and who simply needs to stay informed.

For example, if one sponsor wants speed, another wants cost savings, and a third wants risk reduction, I would ask which metric is the tie-breaker if they conflict. I would propose a shared scorecard with 2 or 3 measures, such as revenue impact, operational risk, and delivery date, then ask the accountable executive to make the final call in writing.

While the debate is happening, I would keep teams executing on work that is not dependent on the unresolved choice, pause only the parts that could be wasted, and communicate a clear interim plan. The goal is to prevent thrash, protect momentum, and get everyone back to one set of success criteria.

For example, on a customer-onboarding automation initiative, three executives disagreed about halfway through: the VP of Engineering wanted to prioritize system reliability given a recent outage, the VP of Finance wanted to prioritize cost savings from reduced manual onboarding labor, and the VP of Risk wanted to prioritize compliance controls given a pending audit. In the decision session, the RACI mapping made the VP of Product the accountable decision-maker, with all three VPs as consulted. The proposed scorecard used three metrics: onboarding error rate (tied to reliability), manual labor hours saved per month (tied to cost), and number of unresolved audit findings (tied to risk). The accountable VP decided that the audit-findings metric was the tie-breaker for this quarter, since the audit deadline was fixed and immovable, while the reliability and cost metrics would be weighted equally starting the following quarter. While that decision was being finalized in writing, the teams kept building the shared onboarding data pipeline, which every option needed regardless of the outcome, and paused only the specific reporting dashboard whose design depended on which metric ultimately won.

Direct answer

The right first step is not to jump straight to a query, but to confirm the suspicion is real: split the existing conversion metric by device type and check whether the gap between mobile and desktop is large enough, and consistent enough over time, to be worth investigating further before proposing changes.

Structured elaboration

Concretely, this means running a query that computes conversion rate separately for mobile and desktop sessions over a recent, representative window (avoiding a single unusual day), and checking the result holds across at least a few weeks rather than being a one-off blip. If a real and persistent gap is confirmed, the next step is to visualize it in a way that makes the SIZE of the gap and its trend over time legible at a glance, typically a simple time series with mobile and desktop as two separate lines, since a single point-in-time comparison cannot show whether the gap is stable, widening, or narrowing.

From there, the statistical question becomes whether the observed gap could plausibly be explained by normal variation given the sample sizes involved, which calls for a two-proportion significance test (comparing the mobile conversion rate to the desktop conversion rate as two independent proportions) rather than eyeballing the percentages, especially if one of the two groups has a meaningfully smaller sample size. Only once the gap is confirmed as both real and statistically distinguishable from noise does it make sense to bring the finding to product prioritization, since presenting an unconfirmed or statistically weak gap risks sending a team to fix a problem that may not actually exist.

Worked example

Suppose a two-week pull shows 40,000 desktop sessions converting at 4.8% and 65,000 mobile sessions converting at 3.6%, a 1.2-percentage-point absolute gap. A two-proportion test on those counts (1,920 desktop conversions out of 40,000 versus 2,340 mobile conversions out of 65,000) is the right way to check whether a gap of that size, given those sample sizes, is unlikely to be due to chance, rather than asserting significance from the percentage difference alone; with sample sizes this large, a gap of 1.2 points would typically clear a standard significance threshold, which is itself useful information; a much smaller gap, or a much smaller sample, might not. If confirmed, the visualization for product prioritization would plot the weekly mobile and desktop conversion rates as two lines over the same two-week window, making clear whether the gap has been consistent or is a recent development.

Trade-offs and pitfalls

A common mistake is treating a single day or a single small sample's device split as conclusive, when device-level conversion rates can be noisy day to day for reasons unrelated to a real UX gap, such as a marketing campaign that happened to skew heavily toward one device that day. Another common mistake is stopping at "mobile converts worse than desktop" without segmenting further, since a device-level gap is often really concentrated in a specific step of the flow (for example, a form that is hard to fill in on a small screen), and the device split alone will not reveal which step to fix.

Direct answer

Do not treat this as picking a winner among the three stakeholders' asks; treat it as scoring every candidate metric, including ones nobody explicitly proposed, against a shared rubric (alignment to company goals, actionability, whether it is a leading or lagging signal, and how much it overlaps with something else already on the page), then keep the three with the best combined profile. In practice that usually means keeping one true north-star or engagement metric, one monetization metric like monthly recurring revenue (MRR), and one health metric like retention, while moving a purely acquisition-flavored ask like installs to a channel-specific dashboard instead of the shared homepage.

Structured elaboration

Selection criteria

• Goal alignment: does the metric map to a current company objective (growth, monetization, retention)?
• Actionability: can a team change their behavior based on this number, or is it purely descriptive?
• Leading vs. lagging: does it warn you early, or only confirm what already happened?
• Uniqueness: does it duplicate information another metric on the same dashboard already carries?

Reconciling the conflict

Run a short working session with a representative from each stakeholder group, score every candidate against the four criteria on a simple 1-5 scale, and let the scores, not seniority or volume of asking, decide the final three. When two metrics score close to tied, prefer the one with better actionability, since a dashboard's job is to trigger a decision, not just to report a number.

Worked example

Score four candidates (the three originally requested, plus a genuine north-star candidate nobody named) on a 1-5 scale across the four criteria:

The three highest scores are core-action weekly active users (18), 30-day retention (16), and MRR (15). Installs (12) is the lowest scorer, mainly on actionability (a rising install count by itself does not tell product or customer-success teams what to do), so it moves to marketing's own channel dashboard instead of the shared homepage, while the shared homepage carries the north-star, monetization, and health signal.

Trade-offs & pitfalls

Scoring feels objective but the scores themselves are judgment calls; running the exercise with only one stakeholder group in the room reproduces the original conflict under a veneer of rigor. A common wrong turn is picking three metrics that all lag together (installs, MRR, and a trailing retention number), which looks balanced on paper but gives nobody an early warning signal; deliberately keep at least one leading indicator in the final set. Dropping a stakeholder's requested metric entirely, rather than relocating it to a dashboard where it is actually actionable, tends to resurface the same disagreement at the next planning cycle, so pair the decision with where the dropped metric still lives.

Direct answer
A data-quality issue caught in a production BI (business intelligence) report, wrong totals, duplicates, or missing rows, usually starts with someone noticing the number looks off, not with an automated check catching it first, which is itself a useful signal about what to fix afterward: strengthening detection so the NEXT issue is caught by monitoring rather than by a stakeholder's suspicion.

Structured elaboration
How it's typically detected: either a stakeholder flags a number that doesn't match their own expectation or a separate source they trust, or, in a better-instrumented setup, an automated check (a reconciliation or anomaly-detection check, the kind) catches it before anyone downstream sees the wrong number at all.

Root-cause investigation: working backward from the symptom, are the wrong numbers coming from a transformation bug (a join fanning out rows, causing duplicates), a source-data problem (the upstream system itself sent bad data), or a timing issue (the report ran before all the day's data had landed). Checking the pipeline's logs and re-running the relevant transformation step against a known sample is usually faster than guessing.

Fix and prevention: the immediate fix corrects the specific issue (deduplicating, correcting a join, re-running with the right data), and prevention means adding a specific automated check that would have caught this exact class of problem next time, closing the detection gap, not just fixing this one instance.

Worked example
A quarterly report shows total order count roughly 8% higher than the finance team's own independently-tracked figure. Detection: a finance analyst flagged the discrepancy after comparing it against their own tracking, not an automated check, since none existed for this specific report at the time. Root-cause investigation: tracing the pipeline revealed a recent change joined the orders table to a new promotions table to compute a discount-eligibility flag, and that join was one-to-many (a small number of orders had multiple matching promotion records), silently duplicating those orders in the final count. The fix: correcting the join to deduplicate before the final aggregation, and reprocessing the affected historical period. Prevention: adding a row-count reconciliation check comparing the source orders table's row count against the final reporting table's row count after every pipeline run, specifically the kind of check that would have caught this exact fan-out bug the moment it was introduced, rather than a month later when a finance analyst happened to cross-check manually.

Trade-offs and pitfalls
A fix that corrects the immediate wrong number without adding the specific preventative check that would catch the same class of bug again is only half the job, and it's tempting to stop there once the pressing issue is resolved, especially under time pressure to move on to the next task; the discipline of actually closing the detection gap, not just the immediate symptom, is what distinguishes a genuinely learned lesson from a one-off fix that the same bug pattern can reintroduce later in a different part of the pipeline.

Direct answer

Missing completely at random (MCAR) means the chance a value is missing has nothing to do with any variable in the dataset, observed or not, like a random sensor glitch. Missing at random (MAR) means the chance of missingness depends on OTHER observed variables but not on the missing value itself, like older survey respondents being more likely to skip an income question. Missing not at random (MNAR) means the chance of missingness depends on the value that's actually missing, like high earners specifically declining to report their income.

Why the distinction matters

The mechanism determines whether ignoring the missingness (or a simple imputation) will bias your conclusions. Under MCAR, the observed data is a random subsample of the full data, so simple approaches introduce little bias. Under MAR, you can often correct for the pattern because the information you need to explain the missingness is sitting right there in other columns. Under MNAR, the missingness itself carries information you can't recover just by looking at the rest of the row, since the very thing that's missing is what's driving whether it's missing.

Worked example

Consider a customer survey: a "device model" field missing because of a random logging bug affecting a random 2% of sessions is MCAR. A "household income" field missing more often for older respondents, but at the same rate regardless of their actual income once you condition on age, is MAR: age is observed, and it explains the pattern. A "household income" field missing specifically because high earners are less willing to disclose it, even after accounting for age and every other observed variable, is MNAR: the value's own magnitude is driving whether you see it at all.

Trade-offs and pitfalls

In practice, you rarely get to observe the true mechanism directly since it's a statement about unobserved values, so you're always making an educated diagnosis from indirect evidence (patterns of missingness across other variables, domain knowledge about why people don't report something) rather than a proof. Treating every missingness pattern as MCAR by default because it's the simplest assumption is the single most common way EDA quietly understates how much a dataset's blind spots matter.

Direct answer

Use a z-test only when the population standard deviation is genuinely known in advance, which is rare in practice. Use a t-test whenever the standard deviation has to be estimated from the sample itself, which is the normal situation, and this holds regardless of sample size. Sample size affects a different thing: how close the t and z critical values are to each other and how much you can lean on the Central Limit Theorem if the underlying data isn't very normal.

Structured elaboration

Known vs. unknown variance. This is the formal criterion. If $\sigma$ is known (rare outside quality-control settings with a long-established process variance), use z. If $\sigma$ is estimated from the sample as $s$ (the normal case), use t with $df = n-1$; the t-distribution's heavier tails are exactly the correction for the added uncertainty of estimating $\sigma$ rather than knowing it.

Sample size's actual role. As $n$ grows, $t_{n-1}$ converges to $z$, so at large $n$ the choice barely changes the numeric answer, which is why "just use z for n≥30" survives as a practical shortcut even though it's not the formal reason. Separately, larger $n$ also makes the Central Limit Theorem a stronger justification for treating the sampling distribution of the mean as approximately normal even when the raw data isn't, which matters for the validity of either test, not for the t-vs-z choice itself.

Comparing two means: pooled vs. Welch's t. If assuming the two groups have equal population variances, use the standard (pooled) two-sample t-test. If variances might differ, and there's rarely a strong reason to assume they're equal, use Welch's t-test, which does not assume equal variances and adjusts the degrees of freedom accordingly. Welch's costs very little power when variances actually are equal but protects against inflated Type I error when they aren't, which is why it's the safer default.

Robustness. t-tests are reasonably robust to mild-to-moderate non-normality once $n$ is moderate (roughly 30+ per group), thanks to the CLT. They're not robust to strong skew or heavy outliers at small $n$, where a few extreme points can dominate both the mean and the variance estimate.

Worked example: how close t and z actually are, by sample size

(All values from scipy.stats.t.ppf(0.975, df), verified directly.) At $df=5$ the t critical value is about 31% larger than z, meaningfully widening the interval or raising the bar for significance; by $df=60$ the gap has shrunk to about 2%. This is the practical justification behind "large n, t and z are basically the same," even though the theoretically correct reason to pick t is always "σ is estimated," not "n is small."

When variances are unknown and sample sizes are small: the actual procedure

1. Look at the data: a histogram or Q-Q plot per group, and check for obvious outliers.
2. If approximate normality looks plausible, default to Welch's t-test (not pooled, unless there's a specific reason to believe variances are equal, such as both groups measuring the identical underlying process).
3. If normality looks clearly violated, or the sample is extremely small (single digits per group) with visible skew, switch to a nonparametric alternative like the Mann-Whitney U test, or use a bootstrap for the confidence interval and p-value instead of the t-distribution's analytic formula.

Trade-offs & pitfalls

• Defaulting to the pooled t-test "because it's the classic one" without checking the equal-variance assumption is a common shortcut that inflates false positives when variances genuinely differ; Welch's is essentially free insurance against this.
• Small samples with heavy skew or outliers can pass a superficial normality check while still producing an unreliable t-test; this is where nonparametric or bootstrap alternatives earn their keep, not just as a formality but as a real fix.
• The "n≥30 use z" heuristic is useful as a rule of thumb but wrong as a justification; it should never be given as the reason to choose z over t in an interview answer, since the real criterion is whether σ is known.

Direct answer
When a mentee gets defensive and stops acting on feedback, the fastest way to make it worse is to double down with more direct feedback. Slow down, diagnose why the message isn't landing (the content, the delivery, or something the mentee brings into the room), then rebuild the conversation as a two-way one instead of a one-way correction. If the pattern doesn't shift after a genuine attempt at that, it needs to be named and escalated, not quietly tolerated.

Diagnose before you re-deliver

• Separate "defensive because of how I said it" from "defensive because of what's underneath it." Workload, unclear expectations, a confidence hit, or feedback that reads as a character judgment rather than a specific behavior all produce the same surface symptom (pushback, non-action) for different reasons.
• Ask, don't assume: open with a genuinely curious question rather than a repeat of the critique. "Walk me through how that landed for you" gets you information; "you need to stop being defensive" gets you more defensiveness.

Use motivational interviewing instead of more direct pressure

• Motivational interviewing is built for exactly this: someone who may intellectually agree but is resisting behaviorally. Instead of arguing for the change, reflect their own stated goals back to them and let them articulate the gap ("You mentioned you want to lead the next project. How does this pattern affect that?"). People act on reasons they generate themselves far more than reasons handed to them.
• Keep the ratio of affirmation to correction visible. If every interaction is corrective, the mentee starts hearing footsteps before you speak, which is what produces reflexive defensiveness.

Rebuild the mechanism, not just the next conversation

• Shrink the ask: instead of a broad critique, propose one small, concrete, reversible change and a short check-in window.
• Make feedback bidirectional: ask what kind of feedback has landed well for them before, and adjust format (written vs. verbal, immediate vs. batched) accordingly.

Know when coaching has run its course

• If, after two or three honest attempts using the above, the pattern is unchanged (commitments still not acted on, same defensiveness), that's a signal the issue may be outside what coaching alone fixes: a skill gap being misread as attitude, a values or fit mismatch, or a factor you're not positioned to see.
• At that point, loop in the mentee's manager, or HR if the dynamic has become adversarial, rather than continuing to privately absorb it. Frame it factually: what you tried, what changed, what didn't. This isn't giving up on the mentee; it's recognizing some situations need authority or context you don't have.

Worked example
A mentee kept missing agreed follow-ups on code review comments and would get visibly short in Slack whenever it came up. The instinct was to restate the same feedback more firmly. Instead, the better move: open the next 1:1 with "I want to understand how the review feedback has been landing for you, not go through it again," and listen first. It turned out the mentee had inherited a legacy module nobody had explained well, and every review comment felt like it was pointing out someone else's mess. The fix wasn't more feedback, it was pairing on the module once and shrinking the ask to one file at a time. If that hadn't worked, the next honest step would have been raising the pattern with the mentee's manager, not repeating the same conversation a fourth time.

Trade-offs and pitfalls

• The junior mistake is treating defensiveness as a discipline problem and pushing harder; that reliably produces more resistance, not less.
• Over-correcting the other way (going silent on real issues to avoid triggering defensiveness) just delays the same conversation and lets performance drift.
• Escalating too early, before you've tried adjusting your own approach, reads as offloading a coaching problem; escalating too late lets a stalled dynamic damage trust or delivery. The senior move is trying a genuine adaptation first, timeboxing it, and being honest about whether it moved anything.

Direct answer

LEAD(start_date) OVER (PARTITION BY user_id ORDER BY start_date) pulls each subscription's next start date into the current row without a self-join, so the gap between one subscription ending and the next beginning is just next_start_date - end_date. A NULL from LEAD means there is no next subscription: label those rows deliberately (commonly "churned"), and pick a business threshold for the gap (say, resumed if the gap is at most 30 days, churned otherwise). The exact same LEAD-over-a-partition idea, applied to a purchases table ordered by purchase_date instead of a subscriptions table, computes time-to-next-purchase for a churn or customer lifetime value (LTV) feature; the one thing that changes is how you treat the rows where LEAD is NULL, because "no next purchase yet" is not the same fact as "this user will never purchase again."

Structured elaboration

• LEAD(col) is the mirror of LAG(col): it reaches forward instead of back, using the same PARTITION BY/ORDER BY contract.
• Gap-based labeling: next_start_date - end_date gives the number of days a customer went without an active subscription; a negative gap means the next subscription started before the current one ended (overlap), which needs its own explicit handling rather than silently falling into "resumed."
• The identical query shape applied to purchases(user_id, purchase_date) gives time_to_next_purchase = LEAD(purchase_date) - purchase_date per purchase, which is a standard input feature for churn models and one building block of an LTV estimate.
• Right-censoring: for a user's most recent purchase, LEAD returns NULL because there simply is no later row in the data you have so far, not because the user is confirmed to never buy again. Treating every NULL as "never" biases the feature toward pessimism for exactly your most recently active users, who are the ones you have had the least time to observe. The standard fix is to compute against an explicit snapshot/as-of date: report "days observed since this purchase with no repeat yet" instead of pretending the time-to-next-purchase is either 0 or infinite.

Worked example

WITH nxt AS (
  SELECT user_id, start_date, end_date,
    LEAD(start_date) OVER (PARTITION BY user_id ORDER BY start_date) AS next_start_date
  FROM subscriptions
)
SELECT user_id, start_date, end_date, next_start_date,
  CASE WHEN next_start_date IS NULL THEN NULL ELSE next_start_date - end_date END AS gap_days,
  CASE
    WHEN next_start_date IS NULL THEN 'churned'
    WHEN (next_start_date - end_date) <= 30 THEN 'resumed'
    ELSE 'churned'
  END AS status
FROM nxt ORDER BY user_id, start_date;

Executed against a 4-row subscriptions sample for two users: user 1 has three subscriptions (Jan 1 to Mar 1, Mar 20 to Jun 1, Sep 1 to Oct 1). The first gap is 19 days (Mar 1 to Mar 20), labeled resumed; the second gap is 92 days (Jun 1 to Sep 1), labeled churned; the third row has no next subscription, so next_start_date and gap_days are NULL and status is churned. User 2's single subscription also has no next row and is labeled churned.

The LTV variant, executed against purchases(user_id, purchase_date) with user 1 buying on Jan 1, Jan 15, and Mar 1, 2024, and a snapshot date of Apr 1, 2024 (2024 is a leap year, so February runs to the 29th; the 46-day gap below only reproduces with that extra day): days_to_next_purchase is 14 (Jan 1 to Jan 15) and 46 (Jan 15 to Mar 1); the Mar 1 purchase has next_purchase_date = NULL and, computed against the Apr 1 snapshot, days_observed_since_this_purchase = 31. That last row is the right-censored one: 31 days with no repeat purchase yet is a very different signal from "31 days and counting, still nothing," and both are different again from a user whose gap of 46 days between purchases is fully observed.

Trade-offs & pitfalls

• The resumed/churned gap threshold is a business decision, not a mathematical one; validate 30 days against the actual distribution of real reactivation gaps rather than hardcoding a round number.
• Conflating "no next row yet" with "will never return" quietly turns an LTV or churn feature into one that systematically under-predicts value for your newest active users, since they have had the least time to generate a "next" row.
• Overlapping subscriptions (next_start_date < end_date) produce a negative gap; decide explicitly whether that counts as resumed, gets clamped to 0, or is flagged as a distinct overlap state, rather than letting it silently pass the <= 30 check.
• LEAD avoids a full self-join scan for this pattern, but still needs an index on (user_id, start_date) (or purchase_date) to stay cheap on large tables, since the engine still has to sort or seek within each partition.

Direct answer. Treat this as a correctness bug first and a performance question second: reproduce the discrepancy with a small, hand-checkable slice of data, isolate whether NULLs in the join or grouping column are the cause, and only then decide on a fix, since the fix for a correctness bug (get the right answer) is different from a performance fix (get the same answer faster).

Structured elaboration. NULL has three-valued logic in SQL: comparisons against NULL evaluate to UNKNOWN rather than true or false, which silently drops rows from equality-based joins and, notoriously, can make a whole NOT IN predicate evaluate to nothing at all if the subquery's result set contains even one NULL. To diagnose, reproduce the discrepancy on a small, deliberately-constructed sample where you can hand-count the correct answer, then narrow down which specific column and which specific operation (a join condition, a NOT IN, an aggregate that's supposed to include a NULL group) is where the count diverges from what you expect.

Once confirmed, the fix is a data-modeling and query-writing decision, not primarily a performance one: decide explicitly what SHOULD happen to NULLs in that join or filter (should an order with no assigned category be included or excluded from a report? should a NOT IN become a NOT EXISTS, which handles NULLs correctly?) and make the query say that explicitly rather than relying on default three-valued-logic behavior that happens to look right on data without NULLs and silently breaks the moment a NULL appears.

Worked example. A "customers without a completed order" report written as customer_id NOT IN (SELECT customer_id FROM orders WHERE status='completed') will silently return ZERO customers, not the correct list, the moment even one row in orders has a NULL customer_id (an orphaned or bad-data row), because SQL's three-valued logic makes the entire NOT IN evaluate to UNKNOWN once a NULL is anywhere in that subquery's result. Rewriting as NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.customer_id AND o.status='completed') is unaffected by that same NULL, since EXISTS/NOT EXISTS never has to evaluate a NULL-vs-value comparison the same problematic way.

Trade-offs and pitfalls. Once you've found and fixed one instance of this pattern, treat it as evidence there may be siblings elsewhere in the same codebase, particularly any other use of NOT IN against a column that isn't guaranteed NOT NULL, since this exact defect class tends to recur wherever that same risky pattern was copied or independently reinvented.

Complexity

The fix itself doesn't change the query's complexity class; it changes correctness, which is the more urgent property to restore first.

Edge cases

Any aggregate (COUNT, SUM, AVG) silently ignores NULL values within the aggregated column by default, which is usually correct but worth double-checking explicitly whenever a report's totals look suspiciously low; that's a related but distinct NULL pitfall from the join/membership issue above.