DoorDash ML Engineer Interview Preparation Guide - Entry Level

Direct answer

Averaging independent estimates cancels out uncorrelated errors, so an ensemble's variance shrinks roughly in proportion to how independent its base learners' mistakes are. If the base learners are highly correlated (they tend to make the same mistakes on the same examples), averaging barely helps, because there's nothing uncorrelated left to cancel. Bagging and random forests work by deliberately reducing that correlation, through resampled training data and, for random forests, randomized feature subsets at each split.

Structured elaboration

The variance-reduction mechanism. For $M$ estimators each with variance $\sigma^2$ and pairwise correlation $\rho$ between any two of them, the variance of their average is:

As $M \to \infty$, the first term vanishes but the second converges to $\rho\sigma^2$, a floor set entirely by the correlation between base learners. This is the core intuition: adding more trees keeps shrinking the $\sigma^2/M$ term, but if $\rho$ is large, the ensemble variance plateaus well above zero no matter how many learners you add. Diversity (low $\rho$) is what lets averaging actually pay off.

Why bagging and random forests reduce correlation.

• Bagging trains each base learner on a different bootstrap resample of the training data, so each tree sees a slightly different, overlapping-but-not-identical dataset; their errors become less correlated because they're fit to different noise realizations of the same underlying signal.
• Random forests add a second layer: at each split, only a random subset of features is considered as candidates. This deliberately prevents every tree from all discovering and splitting on the single strongest feature first, which would otherwise make the trees structurally similar (and their errors correlated) even with different bootstrap samples.

Other ways to increase diversity. Varying the base learner's hyperparameters (depth, minimum leaf size) across the ensemble; using different model families entirely (stacking a tree, a linear model, and a neural net); injecting randomness into training (different random seeds, dropout-like row/column sampling); or training on different feature subspaces (the random subspace method). All of these push $\rho$ down, which is where most of the practical ensemble gain comes from once you already have reasonably accurate individual learners.

Worked example

Fix $\sigma^2 = 1$ and $M = 100$ base learners, and compare two correlation regimes:

Going from $\rho=0.30$ to $\rho=0.05$, holding $M$ and $\sigma^2$ fixed, drops the ensemble variance from $0.307$ to $0.0595$, a reduction of about $81\%$, even though the number of trees and each individual tree's own variance didn't change at all. That's the diversity mechanism in isolation: the same $M$, the same per-tree quality, but a five-fold better ensemble outcome purely from decorrelating the errors, which is exactly what random forests' extra feature-subsampling step is designed to do relative to plain bagging.

Trade-offs & pitfalls

• Diversity is not free: features or hyperparameter choices that increase diversity often do so by making individual base learners slightly weaker (e.g., a very small feature subset per split can starve a tree of its best signal). The formula above assumes $\sigma^2$ is held fixed, but in practice pushing $\rho$ down can push $\sigma^2$ up if taken too far, and the net effect on ensemble variance can reverse.
• The floor $\rho\sigma^2$ means that beyond a certain point, adding more trees has rapidly diminishing returns; the marginal value of tree number 500 versus tree number 100 is small once $M$ is already large enough that $\sigma^2/M$ is small relative to $\rho\sigma^2$.
• This formula addresses variance only; it says nothing about bias, so an ensemble of biased base learners stays biased no matter how diverse they are.
• The independence/correlation framing is intuitive but approximate for classification (0/1 loss) rather than squared-error regression; the qualitative conclusion, correlated errors limit ensemble gains, carries over, but the exact algebraic form above is derived for a variance-of-the-mean setting.

Direct answer

Treat "cloud versus on-prem" as a bucket of many individually testable differences, not one atomic cause, and isolate it the same way you would isolate any multi-variable regression: get a coarse yes/no answer first by running training in the new cloud environment with every candidate axis pinned back to the on-prem configuration, then flip the axes back to their cloud defaults one at a time to find which specific one actually explains the drop. Guessing which difference is responsible without this elimination step is the most common way this kind of investigation stalls.

Structured elaboration

Enumerate the full environment-difference checklist before touching anything. Six independent axes commonly differ between an on-prem box and a cloud GPU instance, and any or all of them can move at once during a migration: (1) GPU architecture, driver version, CUDA (Compute Unified Device Architecture, the platform that lets code run on an NVIDIA GPU) toolkit version, and cuDNN (NVIDIA's library of deep-learning primitives) version; (2) default numeric-precision paths, notably TF32, a reduced-precision matrix-multiply mode enabled by default on certain newer NVIDIA tensor cores, which can silently activate on new cloud hardware without a single line of code changing; (3) non-determinism knobs such as convolution-algorithm auto-tuning, which can select a different algorithm on different hardware even with the same seed; (4) data loading and sharding, where a different number of worker processes or a different node topology can change the effective order or composition of batches even when the top-level seed is identical; (5) framework and dependency versions, where a newer library version can silently change a default; (6) hyperparameters that look identical on paper but are actually environment-conditional, most commonly a batch size that auto-scales to available GPU memory, which changes the effective gradient statistics even when every explicit config value was copied over unchanged.

Reproduce first, before isolating. Pin an identical data snapshot and an identical explicit seed for both the on-prem and cloud runs, and capture a full environment manifest for each (driver, CUDA, cuDNN, framework, and every relevant library version, plus the actual GPU model), so "the same experiment" is a verifiable claim rather than an assumption. Confirm the regression reproduces consistently across at least two runs on the cloud side before spending effort isolating it, since a one-off flaky run is a different, easier problem than a persistent regression.

Isolate to one specific difference with a coarse-then-fine bisection. First, run training in the cloud environment with as many axes as feasible pinned back to the on-prem configuration at once: disable TF32 and any reduced-precision fast paths, force deterministic algorithm selection, match the data-loader worker count and sharding, pin the exact same library versions via the same container image, and pin the same batch size rather than letting it auto-scale. If that maximally-pinned cloud run recovers the on-prem AUC, the regression is confirmed to live somewhere in this checklist, not in a fundamentally different cause (a genuine data problem, a code bug unrelated to environment). Then flip exactly one axis at a time back to its cloud default, re-run, and re-measure, until the AUC drop reappears; the axis whose reintroduction reproduces the drop is the isolated cause. This one-at-a-time step is what "isolating to one specific difference" actually requires; stopping at "the coarse pinned run fixed it" only proves the cause is somewhere in the checklist, not which item.

Worked example

An actually-executed illustration of the precision axis specifically, since it is the one candidate that can be demonstrated without needing GPU hardware: computing the same matrix multiplication in float64 (double precision) versus float32 (single precision, the level of precision a reduced-precision tensor-core path would push even further below) on a fixed, seeded 2048x2048 random matrix pair.

import numpy as np

rng = np.random.default_rng(seed=94)
n = 2048
A64 = rng.standard_normal((n, n)).astype(np.float64)
B64 = rng.standard_normal((n, n)).astype(np.float64)
A32, B32 = A64.astype(np.float32), B64.astype(np.float32)

C64 = A64 @ B64
C32 = (A32 @ B32).astype(np.float64)

abs_diff = np.abs(C64 - C32)
print("max abs diff:", abs_diff.max())
print("mean abs diff:", abs_diff.mean())
print("logit_sum (float64):", C64.sum())
print("logit_sum (float32 compute):", C32.sum())
print("relative diff in summed scalar:", abs(C64.sum() - C32.sum()) / abs(C64.sum()))

Actual output:

max abs diff: 0.0004606311491102133
mean abs diff: 2.577116595525687e-05
logit_sum (float64): -5735.364531135827
logit_sum (float32 compute): -5735.349474763556
relative diff in summed scalar: 2.6251813967851895e-06

This confirms precision alone is a genuine, measurable, isolatable difference (a per-element difference and a summed-scalar relative difference of about 2.6 parts per million here), and it is exactly the kind of candidate the bisection method above would rule in or out by forcing both environments onto the same numeric path and re-measuring the actual AUC. It is not, on its own, evidence that precision explains an AUC drop of several points: a few-parts-per-million difference in a single matrix multiply is a plausible contributor once compounded across millions of operations in a deep network, but it is a small effect relative to what a several-point AUC swing usually needs, and the checklist's other candidates (a changed effective batch size, a dataloader silently sharding data differently, a disabled or reordered augmentation step) are individually far more likely to produce a swing that size on their own. The value of this worked example is demonstrating the elimination technique on a candidate that can actually be measured here, not asserting which of the six checklist items is the real cause on this specific migration; that answer only comes from running the same one-axis-at-a-time process against the real training job.

Trade-offs and pitfalls

• Stopping at the coarse pinned-run result is a common shortfall. Confirming that pinning everything back to on-prem fixes the regression proves the cause lives in the checklist; it does not by itself say which item, and a team under time pressure sometimes ships that partial answer as if it were the root cause.
• Assuming precision is the culprit because it is the easiest difference to demonstrate is a trap. The worked example above intentionally shows this: the effect is real and measurable, but its magnitude alone should not be mistaken for an explanation of a large metric swing without actually testing it against the real training job's AUC.
• An auto-scaling batch size is one of the most underestimated candidates on this checklist. It looks like "the same hyperparameters" in a config file while silently producing different effective gradient noise and different optimization dynamics purely because the new GPU has more or less memory than the old one; it deserves to be pinned explicitly, not left to infer from available memory.
• Treating "cloud versus on-prem is inherently unreproducible" as an excuse to stop investigating is the worst outcome here. Every one of the six checklist items is individually pinnable and individually testable; the investigation is tedious, not impossible, and giving up on isolation after the first confirming coarse test leaves the actual fix undiscovered.

Ways to split the work

• Data parallelism. Each GPU holds a full copy of the model and processes different batches. It is simplest, but the model must fit on one GPU.
• Tensor parallelism. Each layer is split across GPUs. This helps when the layers themselves are too large, but it adds communication every layer.
• Pipeline parallelism. Different layers live on different GPUs. This reduces memory pressure, but can leave devices idle if the pipeline is not balanced.
• Sharded optimizers or fully sharded data parallelism. These split parameters, gradients, and optimizer state to reduce memory use while keeping the training code closer to data parallelism.

How I would choose
If the model is only slightly too big for one GPU, I would prefer sharded data parallelism because it is usually the easiest path. If individual matrix multiplies are the memory or compute problem, tensor parallelism may fit better. If the model is very deep and activations dominate, pipeline or hybrid parallelism can help.

Worked example
For an 8 GPU cluster and a model that almost fits on one device, I would first try sharding plus data parallelism before moving to a more complex hybrid design.

The tradeoff is always simplicity versus communication cost versus memory savings.

Direct answer

You measure whether your communication actually works the same way you'd measure any other process: define what 'acted on' looks like concretely, instrument it, and track it over time, rather than assuming a well-received presentation equals a changed decision.

Structured elaboration

1. Separate 'insight was delivered' from 'insight was acted on.'
Most teams only track the former (a deck was presented, a dashboard exists) because it's easy to observe. The real signal is whether a decision, a roadmap item, or a resourcing choice actually changed as a result. That requires deliberately logging each insight or recommendation as a discrete, trackable unit (a ticket, a decision-log entry, a recommendation ID) rather than letting it live only inside a slide deck that nobody revisits.

2. Define 4-6 concrete metrics that make actionability observable.
A reasonable, non-exhaustive set: (a) share of recommendations formally accepted, rejected, or deferred within a defined window (e.g. 30 days) - the acceptance rate; (b) average time from delivery to a decision being made on it - time-to-decision; (c) share of accepted recommendations that were actually implemented, not just approved - the follow-through rate, since approval without implementation is a common failure mode; (d) measured downstream business impact where an accepted recommendation included a predicted effect (did the metric move the way the insight predicted, and by how much); (e) a stakeholder-reported usefulness or trust score, gathered periodically, as a leading indicator; and (f) recurrence rate of the same insight being re-delivered because it was previously ignored, which is a strong negative signal.

3. Build the minimal data collection to make this trackable, not a large new system.
In practice this is a lightweight log: each insight gets an ID, a delivery date, an owner, a decision outcome, and (if applicable) a link to the metric it was supposed to move. This can live in an existing ticketing or decision-log tool rather than requiring new infrastructure; the discipline is in the LOGGING HABIT, not the tooling.

4. Assign ownership and a reporting cadence.
The team that produces insights (analytics, data science, BI) should own tracking whether insights were delivered and understood; the business owner who received the recommendation should own logging the decision outcome, since they are the one who knows whether it was actually acted on. Report the rollup on a cadence that matches how often recommendations are made (commonly monthly or quarterly) rather than in real time, since 'time to decision' for a nontrivial recommendation is naturally measured in weeks, not hours.

Worked example

A data science team delivers 40 recommendations over a quarter (for example: adjust a pricing tier, change an onboarding step, retire an underperforming feature). They log each with an ID and owner. At quarter end: 28 of 40 were formally decided within 30 days (70% decision rate), of which 19 were accepted, 6 rejected, and 3 deferred; of the 19 accepted, 14 were actually implemented within the quarter (a 74% follow-through rate on acceptances); and of those 14, 9 had a predicted metric attached, of which 6 moved in the predicted direction by at least half the predicted magnitude. The team also finds that 5 of the 40 recommendations were substantively the same insight delivered a second time because the first delivery was never decided on, a recurrence signal that prompts them to investigate why certain recommendation types stall (in this case, three of the five involved a cross-team dependency with no clear single decision-owner). That specific finding, a missing decision-owner for cross-team recommendations, becomes the actionable process fix, which is itself an example of the framework working as intended.

Trade-offs and pitfalls

• The biggest pitfall is conflating 'stakeholders liked the presentation' with 'a decision changed'; a positive reaction in the room is not evidence of actionability and should not substitute for the follow-through metrics above.
• Attributing a downstream metric move entirely to one recommendation is often overclaiming, since other changes happen concurrently; where possible, treat the predicted-impact check as a directional signal, not a rigorous causal claim, and say so.
• A high recurrence rate is more informative than a low acceptance rate; recommendations legitimately get rejected for good reasons, but a recommendation that keeps resurfacing because no one ever decided on it points to a process gap, not a communication gap.
• Do not build a heavy new tracking system before establishing the logging habit manually; teams that try to automate this before anyone consistently logs decisions end up with clean-looking dashboards over incomplete data.

Direct answer

Focal loss adds a modulating factor to standard cross-entropy that automatically down-weights easy, already-well-classified examples, letting hard and minority-class examples dominate the gradient more than they would under plain weighted cross-entropy alone.

Structured elaboration

where $p_t$ is the model's predicted probability for the TRUE class of a given example. The $(1-p_t)^{\gamma}$ term is the modulating factor: when the model is already confident and correct ($p_t$ close to 1), $(1-p_t)^{\gamma}$ is close to 0, shrinking that example's contribution to the loss almost to nothing; when the model is wrong or uncertain ($p_t$ small), $(1-p_t)^{\gamma}$ stays close to 1, leaving that example's loss largely unshrunk.

gamma controls how AGGRESSIVELY easy examples get down-weighted: $\gamma=0$ recovers plain (optionally alpha-weighted) cross-entropy exactly; larger gamma (commonly 2) increasingly focuses training on hard examples. alpha is a more conventional class-balancing weight (like inverse-frequency weighting), applied alongside the modulating factor rather than instead of it.

Focal loss tends to outperform simple class weighting specifically when the majority class contains a large number of EASY examples that a plain weighted loss would still spend a lot of gradient budget on (correctly classifying an obvious majority example over and over contributes little useful signal but still adds up in the total loss); focal loss's modulating factor suppresses exactly that wasted signal, concentrating training on the genuinely informative hard and minority-class cases.

Worked example

For an easy, correctly-classified example with $p_t = 0.95$ and $\gamma=2$: the modulating factor is $(1-0.95)^2 = 0.0025$, so its contribution to the loss is scaled down to a quarter of one percent of what plain cross-entropy would assign it. For a hard example with $p_t = 0.4$: the modulating factor is $(1-0.4)^2 = 0.36$, 144 times larger relative weight than the easy example's factor, concentrating the effective gradient budget heavily on the harder case.

Trade-offs and pitfalls

Focal loss adds two hyperparameters (alpha and gamma) that need tuning, unlike a single class-weight ratio, and an overly large gamma can destabilize training early on, when most examples are still poorly classified and the modulating factor barely shrinks anything, making the effective learning signal noisier than plain weighted cross-entropy until the model starts to separate the classes.

Direct answer
Require every logged run to capture the full hyperparameter configuration, code version (commit hash), data version/hash, the search strategy and its own configuration (e.g. which trial number, which parent search job), all reported metrics (not just the final one), and a pointer to any saved model artifact; design the schema so every field is queryable, not buried in an unstructured notes field.

Structured elaboration
The minimum required fields: (1) hyperparameter configuration, as structured key-value pairs, not a free-text description; (2) code version, an exact commit hash, so the training logic that produced this run is unambiguous; (3) data version, a hash or versioned dataset identifier, not just a path (paths can point to silently-changed data); (4) parent search job ID and trial number, so any individual run can be traced back to which broader search it belonged to; (5) all reported metrics across training (not just the final validation score), since intermediate metrics support the kind of post-hoc trial analysis (marginal plots, learning-curve inspection) discussed elsewhere; (6) a pointer (not the artifact itself necessarily) to the saved model/checkpoint, so a specific run's actual trained model can be retrieved later, not just its recorded metrics.
Auditability design: structure the schema so you can later ask questions like "show me every run in the last quarter that used dataset version X" or "which search job produced the model currently in production" via a query, not by manually digging through logs; this generally means normalizing configuration and metadata into queryable columns/fields rather than dumping everything into an unstructured JSON blob or a free-text notes field that isn't indexed.

Worked example
A run record: {run_id, search_job_id, trial_number, config: {learning_rate: 0.01, max_depth: 6, ...}, code_commit: "a3f9e2", data_version: "v2026-07-01-hash8f3c", metrics: {epoch_1_val_loss: ..., final_val_loss: ...}, checkpoint_uri: "s3://.../run_1234/"}. This record supports both "what was the best config in search job 47" and "which data version was used for the model currently serving in production" as direct queries.

Trade-offs & pitfalls
It's tempting to under-specify this schema early ("we'll just log whatever's convenient right now") and backfill structure later; retrofitting a rigid, queryable schema onto years of loosely-logged runs is far more painful than agreeing the required fields upfront, even if it means a little more logging discipline early on.

Problem formalization:

• Environment: M services i∈{1..M}, T decision rounds. Each round t we allocate a vector of discrete resources a_t = (a_{t,1},...,a_{t,M}) from a feasible budget set A (e.g., ∑i c_i a{t,i} ≤ C, per-host caps).
• Reward: stochastic QoS reward r_t = ∑i R_i(a{t,i}, s_{t,i}) where s_{t,i} are unknown service states (load, SLO attainment); we observe rewards (possibly delayed/noisy) after allocation. Objective: maximize cumulative expected reward E[∑_{t=1}^T r_t] (or minimize regret vs best fixed allocation/policy).
• Unknowns: response curves R_i(·) (monotone, possibly concave), cross-service interactions (contention).

Why this is a combinatorial bandit:

• Each action is a combinatorial object (vector allocation under constraints) drawn from an exponential-size set A. Reward decomposes (possibly approximately) over arms (services) but choice couples via budget constraints. Observations may be semi-bandit (per-service feedback) or bandit (only aggregate). This matches combinatorial multi-armed bandits (CMAB).

Algorithmic solutions:

1. Approximate Combinatorial UCB (CMUCB):

• Maintain per-service estimates μ̂_i(a) or parametric models (e.g., diminishing returns curve). Compute optimistic estimates μ̂_i + bonus_i(t) and solve an offline knapsack/ILP to pick allocation maximizing sum of optimistic rewards subject to constraints. Use approximation-aware regret bounds: if offline oracle is α-approx, regret scales O((poly)·T/α). Use structured models (GLM, parametric) to reduce sample complexity.

2. Greedy with submodular objectives:

• If ∑i R_i(a{i}) is monotone submodular in discrete resource units, use greedy hill-climbing per round: iteratively allocate marginal unit with largest estimated marginal gain. With (1-1/e) approximation and confidence bonuses, this gives provable approximate regret. Practical variant: Thompson Sampling + greedy sampling to handle uncertainty.

3. Contextual/parametric bandits:

• Use contextual CMAB: include features (current load, queues). Fit online Bayesian/linear models and use LinUCB/Thompson Sampling over allocations with efficient combinatorial optimization via knapsack solvers.

4. Handling interactions:

• If strong cross-coupling, treat joint arms for small groups or use low-rank factorization of interaction matrix and learn latent factors.

Practical monitoring and risk controls:

• Safety constraints: enforce hard SLO-preserving actions (never drop below reserve allocations), and clipping of exploratory allocations.
• Conservative bootstrapping: begin with off-line A/B tests or simulation to initialize priors; use decaying exploration rates.
• Canary & rollback: stage policy in canary cluster with traffic shadowing; automatic rollback on SLO degradation beyond thresholds.
• Observability: per-service QoS, latencies, error rates, resource usage, and reward attribution with high-cardinality logs; compute regret/expected reward delta vs baseline in real-time.
• Alarm & intervention: require human-in-loop for high-impact allocation changes, throttle exploratory updates when variance or delayed feedback increases.
• Explainability: surface marginal gains used for each allocation decision to operators.

Trade-offs:

• Exact CMAB algorithms give theoretical guarantees but need efficient oracles; greedy/submodular methods scale well and are robust if submodularity approx holds. Contextual models reduce samples but require reliable features.

This design balances provable algorithms with practical safety: start with parametric/contextual CMUCB + greedy allocation, strong monitoring and safety gates, then iterate as more data reduces uncertainty.

Direct answer

Building in-house buys control and long-term cost efficiency at scale, at the price of time-to-market and ongoing operational burden; a managed cloud service buys speed and lower upfront risk, at the price of vendor lock-in and less flexibility. For a mid-size company, the deciding factor is usually whether ML is a core differentiator or a supporting capability.

Structured elaboration

Recommendation path: start on the managed service to validate the ML use case cheaply and quickly; revisit the build decision only once usage, cost, or compliance requirements outgrow what the vendor comfortably supports. The biggest risk of that path is a costly, disruptive migration if you wait too long; mitigate it by choosing a managed service with reasonably open export formats and avoiding vendor-specific lock-in features until the ML capability has proven its value.

Worked example

A company launching its first personalization feature, with two data scientists and no ML platform team, adopts a managed service (for example, a hosted training and serving platform) to ship a first version in six weeks. Eighteen months later, with personalization now touching every core product surface and inference volume ten times higher, the unit economics of the managed service exceed the fully-loaded cost of a small in-house platform team, and the decision flips: the migration is planned around the personalization feature's next major redesign rather than as an emergency cutover.

Trade-offs and pitfalls

The most common mistake is building in-house too early, before the ML use case has proven its value, which sinks a platform-engineering investment into something that might get killed. The opposite mistake, waiting too long to re-evaluate, leads to an expensive and disruptive late migration once the managed service's costs or limitations start to bind.

Direct answer

When an urgent security issue and a sales-critical demo land the same day, the deciding factor is exposure, not who asked more forcefully: what could go wrong if the security issue waits, and what can still be preserved for the demo without touching the risky path. Usually both can be partially served: contain or fix the security issue first, and give sales something real to show that doesn't depend on the vulnerable code.

Structured elaboration

1. Triage both in parallel, fast

Read the security bulletin and the demo request together. Identify exactly which services, data, or endpoints the vulnerability touches, and exactly what the demo needs to show.

2. Weigh exposure, not urgency of the ask

A security issue usually carries broader exposure (any affected customer, potential data risk) than a single demo (one prospective deal). That asymmetry is normally the tiebreaker, but it should be checked rather than assumed: a demo that's the last step before a major renewal can occasionally weigh more than a low-severity, well-contained finding.

3. Look for a path that serves both

A scoped hotfix with a canary rollout (releasing the fix to a small slice of traffic first, watching it closely, then rolling out to everyone once it looks clean) for the security issue, paired with a sandboxed or stubbed version of the feature for the demo, often means sales isn't actually blocked on the mainline fix landing first.

4. Communicate the decision and the reasoning immediately

Both sides need a concrete plan with timestamps, not just a priority call: what's happening, by when, and what the other side gets in the meantime.

Worked example

The patch ships to a small share of traffic first while being monitored, then rolls out fully once confirmed clean. In parallel, a second engineer builds a stubbed version of the requested feature specifically for the demo environment, so sales can present it without depending on the code currently under remediation. Both sides get an update within a couple of hours: security gets an ETA for full rollout, sales gets confirmation the demo will work and exactly how.

Trade-offs and pitfalls

• Defaulting to whichever request comes from the louder or more senior stakeholder, rather than actual exposure, is the most common failure mode here.
• Building a demo-only workaround without labeling it clearly as temporary risks it quietly becoming the real implementation, skipping the proper fix.
• Failing to give both sides a concrete timeline turns a reasonable prioritization call into a trust problem, even when the call itself was correct.
• Treating this as strictly either/or, instead of looking for a path that partially serves both, wastes an option that's usually available.

Direct answer

Use equal-count bins (pd.qcut), not equal-width bins (pd.cut), because customer spend is almost always right-skewed and equal-width bins would dump most customers into one tier. When many customers share the same spend value, quantile edges can collide, and you either merge the colliding bins with duplicates='drop' or, better, carve the tied mass out as its own explicit tier before quantile-binning the rest.

Structured elaboration

Customer spend is heavily right-skewed in almost every real dataset: a large mass of customers cluster at low or common spend levels, with a small number of high spenders stretching the range far out. That shape drives the bin choice.

• pd.cut (equal-width) splits the full min-to-max range into 5 equal-sized intervals. On skewed spend data this tends to put the vast majority of customers into the lowest bin and leave the top bins nearly empty, since a handful of big spenders stretch the range past where most customers actually sit. A "tier" holding 90% of your customers carries almost no discriminating signal for a segmentation model.
• pd.qcut (equal-count) instead chooses bin edges from the data's quantiles, so each of the 5 tiers gets roughly 20% of customers, regardless of how skewed the raw values are. That balance is usually what a segmentation model needs.

df['spend_tier'] = pd.qcut(
    df['total_spend'], q=5,
    labels=['tier_1_low', 'tier_2', 'tier_3', 'tier_4', 'tier_5_high']
)

Under the hood, qcut computes the 0th, 20th, 40th, 60th, 80th, and 100th percentiles of spend and uses those six values as the five bin edges.

Worked example: handling collisions

Fixture: 1,000 customers, 400 of them with total_spend == 0, the rest drawn from a right-skewed exponential distribution, which is exactly the shape real spend data takes:

import numpy as np
import pandas as pd

rng = np.random.default_rng(42)
df = pd.DataFrame({
    'total_spend': np.concatenate([
        np.zeros(400),
        rng.exponential(scale=150, size=600),
    ])
})

Both the 20th and 40th percentile of spend are then $0, so two adjacent bin edges come out identical:

df['spend_tier'] = pd.qcut(df['total_spend'], q=5,
                            labels=['tier_1_low', 'tier_2', 'tier_3', 'tier_4', 'tier_5_high'])
# ValueError: Bin edges must be unique: Index([0.0, 0.0, 0.7316480549730886,
#     59.85976344592463, 167.14041699500663, 925.3649472537413], dtype='float64', ...)

Verified by running this exact code against the fixture above: qcut raises ValueError: Bin edges must be unique with the duplicate 0.0 edge shown in the error.

Two ways to handle it, both verified against the same fixture:

1. duplicates='drop' merges the bins that would otherwise share an edge. Quick, but you can end up with fewer than 5 actual tiers, here it collapsed to 4:

df['spend_tier'] = pd.qcut(df['total_spend'], q=5, duplicates='drop')
# resulting value_counts: (-0.001, 0.732]: 400, (0.732, 59.86]: 200,
#                          (59.86, 167.14]: 200, (167.14, 925.36]: 200

2. Carve out the tied mass as its own explicit tier first, then quantile-bin the remainder. If a large share of customers are at $0, that is usually a meaningful group on its own (non-spenders), not something to blend into a quantile split:

zero_mask = df['total_spend'] == 0
tiers = pd.Series(index=df.index, dtype='object')
tiers[zero_mask] = 'tier_0_no_spend'
tiers[~zero_mask] = pd.qcut(df['total_spend'][~zero_mask], q=4,
                             labels=['tier_1', 'tier_2', 'tier_3', 'tier_4'])
df['spend_tier'] = tiers
# resulting counts: tier_0_no_spend: 400, tier_1..tier_4: 150 each

Both were run against the same 1,000-row fixture; the counts above are that run's actual output.

Trade-offs and pitfalls

• Equal-width bins are the right call when the business wants fixed, interpretable dollar thresholds that stay stable across every rerun (e.g. always $0 to $100, $100 to $500, ...) even at the cost of unbalanced group sizes; that is a product decision about interpretability and stability, not a purely statistical one.
• duplicates='drop' is convenient but non-deterministic in tier count: log or check the resulting number of bins rather than assuming you always get 5.
• Both cut and qcut propagate a missing spend value as NaN (not-a-number) rather than assigning it a bin. Decide up front whether a missing spend record means "no purchases" (fillna(0) before binning) or should be excluded and flagged separately, since silently dropping those rows changes your denominator without anyone noticing.
• If new customers arrive after the model is trained, decide whether to recompute qcut boundaries on the new data (tier definitions drift over time) or freeze the boundaries learned at training time and apply them to new data with pd.cut and the frozen edges (stable tiers, matches how most production scoring pipelines need to behave).