Data Preparation and Class Imbalance for ML Questions

Direct answer

IQR-based capping, z-score methods, and Winsorization are simple univariate tools for a single numeric feature; Isolation Forest, Local Outlier Factor, and DBSCAN-based approaches catch multivariate outliers, points that look normal on every individual feature but are jointly unusual. Treatment differs by model: tree-based models tolerate outliers reasonably well, while linear and distance-based models need them addressed directly.

Structured elaboration

Univariate methods (IQR, z-score) only see one column at a time and will miss a point that's individually unremarkable on every feature but jointly anomalous (an unusually high transaction amount for THIS particular customer, even if it's unremarkable across the whole population); multivariate methods are needed to catch that.

Treatment by model type: tree-based models split on thresholds and are naturally robust to extreme values (an outlier just ends up in a leaf by itself, largely uncontaminating other splits), so light or no outlier treatment is often fine; linear models and distance-based models can have their entire fit distorted by even a few extreme points, so capping, transforming, or removing outliers matters much more there.

Worked example

For a feature with $Q1=20$, $Q3=60$ (so $IQR=40$), the IQR fence is $[20 - 1.5\times 40,\ 60 + 1.5\times 40] = [-40, 160]$; any value outside that range is flagged. For skewed data (say, response times heavily right-skewed), this same rule tends to over-flag legitimate large values on the long tail, which is exactly the "advantages and assumptions" caveat: IQR assumes a roughly symmetric distribution, and applying it naively to a skewed one produces more false flags than intended.

Trade-offs and pitfalls

Small-sample caution: with only a handful of data points, quantile-based estimates like Q1/Q3 are themselves noisy, so an IQR fence computed on 20 rows is much less trustworthy than one computed on 20,000.

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.

Direct answer

Condition the GAN or VAE on the minority class (and any other relevant attributes) so it generates class-specific samples deliberately, evaluate the synthetic data on BOTH fidelity (does it look statistically like real minority data) and downstream utility (does training on it actually improve a real model), and treat membership-inference and re-identification risk as a first-class concern, not an afterthought, before using synthetic data derived from real, possibly sensitive, minority examples.

Structured elaboration

Conditioning: a conditional GAN (like CTGAN, purpose-built for tabular data) or conditional VAE takes the class label as an explicit input, letting you generate new samples specifically for the minority class on demand rather than hoping an unconditional model happens to produce useful minority-region samples.

Evaluation metrics for fidelity: compare marginal distributions of individual features (real vs. synthetic) via statistical tests or visual comparison; a "classifier two-sample test" (train a classifier to distinguish real from synthetic examples, if it CAN'T distinguish them well, that's evidence the synthetic data is statistically close to real) is a strong, general-purpose fidelity check.

Evaluation metrics for utility: train a downstream model on real-plus-synthetic data and compare its performance (on a REAL, held-out test set) against a model trained on real data alone, since fidelity alone doesn't guarantee the synthetic data actually helps the task you care about, and utility is ultimately the metric that matters for a production decision.

Training stability concerns: GANs specifically are known for potential mode collapse (the generator producing a narrow range of samples rather than the true diversity of the minority class) and general training instability; monitor generated-sample diversity explicitly during training (not just the loss curves, which can look fine even during partial mode collapse), and prefer a VAE or a more stable GAN variant if training instability proves to be a persistent problem for this dataset.

Privacy risks: membership inference (can an attacker determine whether a SPECIFIC real record was in the training data, by querying the generative model) is a real, measurable risk for models trained on small minority sets specifically, since a generator can effectively memorize and regurgitate near-copies of rare training examples when there's too little real diversity to learn a genuinely general distribution from; test explicitly for near-duplicate synthetic-to-real matches (a nearest-neighbor distance check between every synthetic example and the real training set) as a concrete, checkable privacy safeguard before using or sharing the synthetic data, especially if the underlying real records are sensitive.

Worked example

For a fraud-detection minority class with only 300 real examples, a CTGAN might generate 5,000 synthetic minority samples; the classifier two-sample test finding it easy to tell real from synthetic apart (say, 85% accuracy at distinguishing them) is a red flag the synthetic data isn't statistically faithful yet, while checking nearest-neighbor distances between synthetic and real samples finding several near-exact matches would be a red flag for privacy leakage regardless of how good the fidelity metrics otherwise look.

Trade-offs and pitfalls

Fidelity and privacy pull in genuinely opposite directions at the extreme: a generative model trained to match the real minority distribution as closely as possible, on a very small real dataset, is inherently at higher risk of memorizing and regurgitating near-copies of specific real records, so with a small minority set specifically, it's worth treating "too realistic" as a warning sign worth checking against the nearest-neighbor privacy test, not purely as a success signal.

Direct answer

Frame it as a dial, not a switch: every extra fraud case you catch by loosening the model comes with more false alarms for the review team to work through, and there's a point past which the added review burden costs more than the fraud you're preventing. My job is to help you find where that point should sit, not to promise "catch everything" is free.

Structured elaboration

Translate the trade-off into the vocabulary the stakeholder already uses:

• Recall (the fraction of real cases you catch) is what "catch every case" is asking for.
• Precision (the fraction of your alerts that are real) is what determines how much wasted reviewer time, customer friction, or false-decline revenue loss you generate along the way.

A concrete way to make it tangible: state the current operating point in business units ("today we catch 80% of fraud and our reviewers close 40% of alerts as false positives, costing about 6 reviewer-hours per confirmed fraud case"), then show what pushing recall to 95% would do to that ratio using the model's actual precision-recall curve, not a hypothetical.

Then propose a concrete plan rather than leaving it as an abstract trade-off: agree on a target operating point tied to a resource constraint (how many alerts the review team can actually process per day), commit to it as an SLA, and set up a monitoring dashboard so both sides can see recall, precision, and reviewer load drift over time and revisit the threshold deliberately instead of by surprise.

Worked example

If the review team can handle 200 alerts a day and the model's precision at "catch everything" settings drops to 10%, that's 200 alerts producing only about 20 real cases and 180 false alarms consuming the entire day's capacity, versus a calibrated threshold that might catch 85% of fraud at 45% precision, producing far fewer false alarms per real case caught.

Trade-offs and pitfalls

Three scenarios worth naming explicitly to make the trade-off concrete for a stakeholder: recall should usually win for disease screening (missing a real case is far worse than a false alarm that a follow-up test resolves) and for safety-critical detection; precision should usually win for a marketing-offer trigger or a low-stakes automated action (annoying a customer or wasting a small amount of budget on a false positive adds up fast at scale). The pitfall is presenting this as a purely technical choice: the right operating point is a business decision informed by the technical trade-off curve, and the stakeholder should own the final call once they can see the real numbers.

Direct answer

Handle Unicode normalization first (so the same character isn't represented multiple different byte-level ways), detect the language or script per document (or per segment, for code-switched text), route to a per-language tokenizer where meaningful differences exist, and build a shared vocabulary that lets related languages share subword tokens rather than maintaining entirely separate, non-overlapping vocabularies.

Structured elaboration

Unicode normalization: apply a consistent normalization form (NFC or NFKC) so visually-identical characters that differ at the byte level (accented characters composed differently, full-width versus half-width variants common in East Asian text) get treated as the same token rather than silently fragmenting your vocabulary with near-duplicate entries.

Script and language detection: detect the script (Latin, Cyrillic, Thai, CJK) and, within a script, the specific language, since tokenization needs genuinely differ (whitespace-based word boundaries work for many Latin-script languages but not for Thai or Chinese); for a genuinely multilingual document collection, this detection needs to run per-document or even per-segment if individual documents mix languages.

Per-language tokenization: languages needing fundamentally different tokenization strategies (character-based for Chinese, morphology-aware for agglutinative languages like Turkish or Finnish) should get purpose-appropriate tokenizers rather than forcing one whitespace-based scheme onto all of them.

Shared vocabulary creation: for a multilingual MODEL specifically (not just per-language preprocessing), a jointly-trained subword vocabulary across all target languages lets related languages share tokens for cognates and loanwords, improving cross-lingual transfer, at the cost of needing careful attention to vocabulary allocation so no single high-resource language dominates the shared vocabulary at the expense of lower-resource ones.

Worked example

A dataset mixing English, Chinese, and code-switched Singlish (English-Chinese mixed within single sentences, common in Singapore/Malaysia) needs per-SEGMENT language detection, not just per-document, since a single sentence might legitimately need both a whitespace-aware English tokenizer for part of it and a character-based Chinese tokenizer for another part, a genuinely harder preprocessing problem than either monolingual case alone.

Trade-offs and pitfalls

The shared-vocabulary allocation problem is a real, often underestimated trade-off: if the corpus is 90% English and 10% a mix of 10 other languages, a naively-trained shared subword vocabulary will allocate the vast majority of its capacity to English-optimized tokens, leaving the lower-resource languages with excessive subword fragmentation (very short, uninformative tokens) that hurts their downstream model quality specifically, which is why deliberate vocabulary-allocation strategies (oversampling low-resource languages during vocabulary training, or a temperature-based sampling scheme) are worth the added complexity for a corpus with genuinely imbalanced language representation.