DoorDash Data Analyst Interview Preparation Guide - Staff Level

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.

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
A chart using 12 colors, 3 axes, overlapping lines, no axis labels, and a rainbow palette fails on nearly every principle of clear encoding at once; the fix is to cut the series count, pick one axis per unit of measurement, label everything directly, and replace the rainbow palette with a small categorical or sequential palette matched to the data's actual structure.

Structured elaboration
Six concrete problems and their fixes:

1. Too many series (12 colors): past about 6-8 distinct lines, colors become indistinguishable. Fix: keep the 3-4 series that matter, move the rest to "other" or a drill-down, or switch to small multiples (one mini-chart per series).
2. Three axes: more than two axes (and ideally just one) makes it impossible to know which line maps to which scale. Fix: one axis per unit; if units genuinely differ, use small multiples instead of overlaying.
3. Overlapping lines: dense overlap hides individual series. Fix: reduce series count (as above) or use a small-multiples grid.
4. No axis labels: the chart is uninterpretable without units and time range. Fix: label both axes with units and a time range in the title or subtitle.
5. Rainbow palette: implies false ordering and clashes visually. Fix: a categorical palette of 4-6 distinguishable hues for categories with no order, or a sequential palette for ordered/quantitative series.
6. No annotation of the key insight: even a clean chart still needs a headline for an executive briefing.

Worked example
A revised version for an executive briefing: keep this a time-series comparison (the data is inherently a trend over time), rendered as a decluttered multi-line chart, but with only the top 3 series by magnitude, a single y-axis, direct end-of-line labels instead of a legend, a 3-4 color categorical palette, axis labels with units, and one annotation naming the key takeaway (e.g. "Channel A overtook Channel B in March"). If the audience's actual question is a snapshot comparison rather than a trend (e.g. "who is winning right now"), a sorted horizontal bar chart of the same top 3-4 series is the better chart-type choice instead of a line chart.

Trade-offs and pitfalls
Cutting to 3-4 series means some information is genuinely lost; disclose that the remaining series were grouped into "other" rather than silently dropping them, and offer a drill-down link for anyone who needs the full breakdown.

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.

Direct answer

Build the argument from the sales team's own evidence and in the unit they care about: do we make more money with the feature than without it? Put a dollar figure on what the feature wins, put a dollar figure on what it costs to build, run and support, and show the single number that would have to be true for it to pay off (the break-even). Then soften the reaction by involving sales in testing that number, offering something real in place of a flat "no", and attaching a revisit trigger so the decision is "not yet, and here is the bar" instead of "never".

Step 1: understand the demand before arguing

Pull the last two quarters of opportunity notes and lost-deal reasons. Count how many deals actually named the feature as a requirement (not "would be nice"), their annual contract value (ACV, the yearly subscription value of a deal), taken from the sales team's opportunity notes (their record of each deal), and the win rate (share of deals that close) with and without it. "Popular" often means loud, so the first job is to separate the number of requests from the number of deals blocked.

Step 2: the cost side, in the same units

Include four things: the one-time build, the ongoing maintenance (engineer time, the test matrix, meaning the combinations of settings and customer configurations that must be re-tested each release, and on-call), the extra cost to serve each account that uses it (support tickets, hosting), and the gross margin effect (gross margin is revenue minus the direct cost of delivering the product, as a share of revenue).

Step 3: the arithmetic (illustrative inputs)

Assume ACV $60k, gross margin 78% before the feature, 36 deals a year that mention the feature, a 20% base win rate, and sales claims a 10-point lift if we ship it. The feature adds $9k a year of support and hosting per account that uses it, $120k a year of maintenance, and a $150k build spread over 3 years.

acv, gross_margin = 60.0, 0.78         # $k per account per year
extra_cost = 9.0                       # $k per year extra support and hosting per account using the feature
fixed = 120.0 + 150.0 / 3              # $k per year: maintenance plus a 150k build spread over 3 years
deals, base_win, lift = 36, 0.20, 0.10 # deals per year that mention the feature; win rate; claimed lift
gp_per_account = acv * gross_margin - extra_cost
incremental_gp = deals * lift * gp_per_account
drag = deals * base_win * extra_cost   # extra cost on deals we would have won anyway
print(f"GP per account {gp_per_account:.1f}k ({gp_per_account / acv:.0%} margin)")
print(f"incremental GP {incremental_gp:.1f}k - fixed {fixed:.1f}k - drag {drag:.1f}k = {incremental_gp - fixed - drag:.1f}k per year")
print(f"break-even win-rate lift {(fixed + drag) / (deals * gp_per_account):.1%}")

Output:

GP per account 37.8k (63% margin)
incremental GP 136.1k - fixed 170.0k - drag 64.8k = -98.7k per year
break-even win-rate lift 17.3%

In words: each account that uses the feature earns $37.8k of gross profit instead of $46.8k, so its margin falls from 78% to 63%. The feature wins 3.6 extra deals a year ($136.1k of gross profit) but costs $170.0k of fixed spend, and it also adds $64.8k of cost on the 7.2 deals we would have won anyway. Net: about minus $98.7k a year. It breaks even only if the win-rate lift is 17.3 points, not the claimed 10.

The break-even comes from setting incremental gross profit equal to total cost: lift x 36 deals x $37.8k = $170.0k fixed + $64.8k drag, so lift = $234.8k / $1,360.8k = 17.3%. Here "drag" is the extra cost the feature adds on deals we would have won anyway (36 x 20% x $9k = $64.8k).

The number to take to the room is the 17.3-point break-even: "if lost-deal data shows a lift above that, I will change my view".

Step 4: the operational complexity argument

Convert it into capacity: the $120k a year of maintenance is about half an engineer (at an assumed $240k loaded cost per engineer-year, salary plus overhead), a half-engineer not shipping the roadmap, plus a larger test matrix and more support escalations. State what the half-engineer would do otherwise, with its own estimated return, so complexity is a priced trade and not a vague worry.

Step 5: soften the reaction

1. Pre-wire (brief people privately before the meeting). Share the numbers with the sales leader one-to-one before any group meeting, so nobody is ambushed.
2. Use their data. Review ten lost deals together; if sales finds the lift is real, you update.
3. Offer alternatives, not just a refusal: a narrower version covering the 80% use case, a paid add-on priced to cover its cost to serve, a partner or workaround for the named deals, or a dated revisit.
4. Acknowledge the cost to them in plain words ("this makes your quarter harder") and give enablement (sales materials and training, such as a battlecard, a one-page sheet on how to answer the gap against a named competitor, or a reference customer) for deals where the gap hurts. In the room that sounds like: "This makes your quarter harder and I do not want to wave that away. The numbers say it needs a 17-point win-rate lift to pay for itself and you are claiming 10. Let us review ten lost deals together; if the lift is there I will change my view. Meanwhile here is a narrower version for the named deals."
5. Define the trigger: "if the lost-to-feature rate exceeds X for two quarters, we reopen".

Trade-offs and pitfalls

• Margin dilution is not the whole picture. Customers who use the feature may churn less, which would improve the case; include a retention estimate if you have one, and say it is excluded if you do not.
• One huge strategic logo (a prestigious customer whose name helps win others) can justify an exception. Handle it as a priced custom deal, not a roadmap commitment.
• Never argue from engineering taste ("it is messy"). Argue from money and capacity.
• Do not call sales wrong. The claim is "unproven at the cost we would pay", which is testable.

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

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

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
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.