Data Preparation and Class Imbalance for ML Questions

Direct answer

Standard k-fold shuffles rows randomly across folds, which for time-series data means training on the future to predict the past, information a real deployment would never have. Walk-forward (rolling-origin) validation and an expanding window both fix this by always keeping training data strictly earlier in time than validation data.

Structured elaboration

Walk-forward / rolling-origin: train on a fixed-size window of the most recent past, validate on the next period, then slide the whole window forward and repeat. Expanding window: keep the training start fixed but grow the training window forward each round, so each successive fold trains on more history than the last while validation always stays just ahead of it.

def walk_forward_splits(n, n_splits, val_size):
    """Yield (train_idx, val_idx) using an expanding training window."""
    fold_size = (n - val_size) // n_splits
    for i in range(n_splits):
        train_end = fold_size * (i + 1)
        val_start, val_end = train_end, min(train_end + val_size, n)
        if val_end <= val_start:
            break
        yield list(range(0, train_end)), list(range(val_start, val_end))

for train_idx, val_idx in walk_forward_splits(n=1000, n_splits=5, val_size=100):
    print(f"train=[0,{train_idx[-1]}]  val=[{val_idx[0]},{val_idx[-1]}]")

If the target is ALSO rare within this time-ordered setting (equipment failures, fraud), preserving an approximate positive-class ratio per fold matters too: rather than a purely chronological cut that might leave one window with almost no positives, you can widen the training window for that fold until it captures a reasonable minimum count of positive examples, trading strict recency for a usable minority sample.

Worked example

Running the code above prints five expanding windows: train=[0,179] val=[180,279], train=[0,359] val=[360,459], and so on through five folds, each one training on strictly earlier data than the validation window that follows it, with training set size growing each round while validation size stays fixed at 100.

Trade-offs and pitfalls

Common pitfalls: allowing ANY feature that uses future information (a rolling average computed with a centered window instead of a trailing one, or a label-derived aggregate) to leak across the train/validation boundary even though the ROW split itself is chronologically correct; and forgetting that walk-forward validation naturally produces fewer, larger folds than standard k-fold for the same dataset, so per-fold metric variance needs to be interpreted with that in mind.

Direct answer

Combine rule-based normalization for the common, predictable variants with fuzzy matching for the long tail, route genuinely ambiguous cases to human review, and store the resulting canonical mapping somewhere versioned and reusable so the same standardization applies consistently across every pipeline that touches this field, not just the one that happened to build it.

Structured elaboration

Rule-based normalization first: lowercase, strip whitespace and punctuation, expand known abbreviations via an explicit lookup table (NY → New York, if that direction is the canonical one you've chosen), catching the majority of common variants cheaply and deterministically.

Fuzzy matching for what rules miss: for values that don't match any known rule, score them against the existing canonical values using a string-similarity metric, and auto-accept matches above a high-confidence threshold.

Human-in-the-loop for ambiguous cases: values that fuzzy-match multiple canonical candidates similarly well, or fall in a middle-confidence band, go to a reviewer rather than being auto-resolved by a coin-flip-equivalent threshold decision; each reviewer decision should feed back into either the rule table (if it reveals a new common pattern worth automating) or the canonical mapping directly.

Storing and versioning the mapping: keep the canonical value table (raw variant to normalized value) in a shared, version-controlled location (a database table with an audit log, or a versioned config file) rather than embedded logic scattered across multiple pipelines, so every downstream consumer of this field, not just the pipeline that built the mapping, applies the exact same standardization, and any future correction to the mapping is automatically reflected everywhere it's used rather than requiring a hunt through every pipeline that independently reimplemented the same logic.

Worked example

"NY", "N.Y.", "new york", and "NewYork" all normalize, via a mix of a rule (case-insensitive, punctuation-stripped exact match against a known abbreviation table) and fuzzy fallback, to a single canonical "New York"; a genuinely ambiguous input like "Georgia" (the US state, or the country) would fall outside straightforward automated resolution and route to a reviewer with the surrounding context (other fields in the same record) to disambiguate.

Trade-offs and pitfalls

The most common failure mode in a standardization pipeline like this isn't the matching logic itself, it's DRIFT: a canonical mapping built once and never revisited slowly falls out of sync as new source systems introduce new variants, so treating the mapping table as a living, versioned artifact with an owner and a process for adding new entries (rather than a one-time script output) is what keeps the standardization actually correct over time.

Direct answer

Normalization (min-max scaling) rescales a feature into a fixed range, usually $[0,1]$; standardization (z-score) centers a feature at zero mean with unit variance. Standardization is the safer default for most models because it isn't anchored to the exact min and max seen in training, while normalization is preferred when you need a strictly bounded range, such as feeding pixel intensities into a neural network.

Structured elaboration

Outliers affect the two very differently: a single extreme value inflates $x_{\max}$ (or deflates $x_{\min}$) and compresses every other normalized value toward one end of the range, while standardization's mean and standard deviation are also outlier-sensitive but the effect is comparatively milder since it doesn't hard-clip against two data points.

Model sensitivity: distance-based and gradient-based models (k-NN, SVM, neural networks, anything using Euclidean distance or gradient descent) are sensitive to feature scale because a feature with a larger numeric range dominates the distance calculation or the gradient magnitude purely by virtue of its units. Tree-based methods (Random Forest, gradient boosting) are scale-invariant because they split on threshold comparisons within a single feature at a time, and a monotonic rescaling doesn't change which side of a threshold a value falls on.

Rule of thumb: standardization for neural networks and most classical models by default; normalization specifically when you need a bounded range (image pixel values, or a model like a min-max-based similarity metric that explicitly expects $[0,1]$ inputs); tree models need neither.

Worked example

For a feature with values $[10, 20, 30, 40, 1000]$ (one clear outlier): min-max scaling maps 10→0.0 and 1000→1.0, but now 20, 30, and 40 all crowd into the range $[0.01, 0.03]$, nearly indistinguishable from each other. Standardization on the same data ($\mu = 220$, $\sigma \approx 390.1$) gives z-scores around $-0.54, -0.51, -0.49, -0.46$ for the four normal values and about $2.00$ for the outlier, less visually crushed together though still outlier-influenced through $\mu$ and $\sigma$.

Trade-offs and pitfalls

To recover original units for interpretability, invert the transform: $x = x_{\text{std}} \cdot \sigma + \mu$ (or the corresponding inverse for min-max), using the exact $\mu, \sigma$ (or min, max) computed on the TRAINING data, never recomputed on new data, or you'll silently apply a different transform than the model was trained on.

Direct answer

Data cleaning fixes problems in the raw data itself (wrong types, duplicates, invalid values); data preprocessing transforms already-clean data into a form a model can actually consume (encoding, scaling, imputing what's genuinely and legitimately missing). Cleaning comes first and makes the data trustworthy; preprocessing comes after and makes it model-ready.

Structured elaboration

Concrete cleaning tasks: removing exact or fuzzy duplicate rows; converting a column stored as text into its correct numeric or date type; fixing or flagging genuinely invalid values (a negative age, an order date after the return date); standardizing inconsistent category spellings ("NY" vs "New York") into one canonical form.

Concrete preprocessing tasks: imputing values that are legitimately missing (not wrong, just absent) using a chosen strategy; one-hot or target encoding a categorical feature; scaling a numeric feature; splitting into train/validation/test.

The distinction matters because the two failure modes are different: a cleaning problem (a corrupted or wrongly-typed value) will actively mislead a model or a preprocessing step that trusts it's dealing with valid data, while a preprocessing choice (which encoding, which scaler) is more about model-readiness and performance than about correctness of the underlying facts.

A short workflow: ingest raw data, run cleaning checks and fixes (type conversion, deduplication, invalid-value handling) FIRST, THEN apply preprocessing (imputation, encoding, scaling) on the now-trustworthy cleaned data, and finally split for modeling; running preprocessing before cleaning risks, for instance, imputing a value using statistics computed from data that still contains duplicates or corrupted values, quietly distorting the imputation itself.

Worked example

A "signup_date" column stored as mixed text strings (some "2023-01-02", some "01/02/2023") needs cleaning (parse and standardize the date format) BEFORE any preprocessing step, like deriving a "days since signup" feature, can be trusted; computing that derived feature from unparsed or inconsistently-parsed strings would silently produce wrong values that no amount of correct downstream scaling or encoding could fix.

Trade-offs and pitfalls

Common tools by task: SQL and pandas for both cleaning (deduplication, type casting) and preprocessing (encoding, scaling) on tabular data; Excel or Power Query for smaller, more manual cleaning tasks in a business-analyst context; the boundary between the two isn't always crisp in practice (some tools blur cleaning and preprocessing into one pipeline step), but keeping the CONCEPTUAL distinction clear, is this fixing a data-correctness problem or a model-readiness problem, helps you reason about ordering and about which step to blame when something downstream looks wrong.

Direct answer

Behavioral answer, using the STAR structure: describe a specific situation where a preprocessing or data-quality decision (an imputation choice, a resampling strategy, a fix to a broken date-parsing routine) turned out to materially change a model's behavior or a business outcome, and walk through the reasoning, the validation, and the lesson learned.

Structured elaboration

Situation: set up the concrete context, what model or report was affected and why it mattered (a churn model whose predictions were being used to prioritize a retention team's outreach).

Task: what you were responsible for, specifically (diagnosing why the model's predictions seemed off, or improving a pipeline you inherited).

Action: the actual preprocessing decision and the reasoning behind it, described concretely (discovering that a "days since last purchase" feature was being computed with a bug that included future purchases for churned customers, a leakage bug; or deciding that median imputation on an income field was distorting predictions for a specific segment and switching to a grouped, segment-aware imputation instead).

Result: the measurable outcome, tied to real numbers where possible (validation AUC improved from X to Y, or the retention team's outreach precision improved by Z%, or a specific downstream business metric moved), plus what you validated to confirm the improvement was real (an A/B test, a time-based holdout, not just a training-set number).

Worked example

"I inherited a churn model whose predictions correlated suspiciously well with a 'days_to_cancel' feature. Tracing the feature's derivation, I found it was computed from the FULL customer history including records after cancellation, a leakage bug. I removed the feature, retrained, and validation AUC dropped from an unrealistic 0.94 to a more modest but honest 0.79. I then worked with the team to build genuinely predictive features from PRE-cancellation behavior only, recovering AUC to 0.83 over the following two weeks, a number the team could actually trust for prioritizing outreach, versus the original number which would have looked great in a demo and failed in production."

Trade-offs and pitfalls

The strongest version of this answer names a decision that could have gone WRONG, and shows the reasoning and validation that confirmed it was right, rather than a story where the "right" choice was obvious in hindsight; interviewers are listening for genuine judgment under uncertainty, not just a happy ending.