Privacy and Data Leakage Mitigation

What's being tested

Interviewers probe your ability to identify, quantify and mitigate ways sensitive information or future information can leak through an ML pipeline—both during training and at inference. They expect an MLE to reason about concrete engineering controls (feature splits, feature-store parity, training recipes like `DP-SGD`) and to quantify tradeoffs between privacy/robustness and model utility. Netflix cares because personalization operates on user-sensitive signals; a candidate must show they can design reproducible pipelines, tests, and monitoring that keep models useful without leaking private data.

Core knowledge

Data leakage: when a model has access to information at training that would not be available at inference or when sensitive training examples can be recovered; common types are target leakage, temporal leakage, and membership leakage. Know to name the type and its root cause quickly.
Train/serve parity: ensure the same deterministic transformations and feature versions at training and serving using a feature-store snapshot or export; use `GroupKFold` on user IDs or `TimeSeriesSplit` for temporal problems to avoid future data bleed.
Target encoding leakage: compute category-to-label encodings with out-of-fold/leave-one-out procedures. Formula: target_enc = (sum_y + α·prior) / (count + α); do encoding only on training folds to avoid label leakage into validation.
Duplicate / record contamination detection: fingerprint rows with a cryptographic hash (e.g., `SHA256`) of canonicalized features to find overlaps between train/val/test; dedupe before splitting and ensure user-level splits to prevent cross-contamination.
Differential privacy (DP) basics: a mechanism M is (ε,δ)-DP if ∀ neighboring D,D', S: P[M(D)∈S] ≤ e^ε P[M(D')∈S] + δ. Laplace/Gaussian noise scales with sensitivity; for Gaussian noise, σ ≈ sqrt(2 ln(1.25/δ)) · sensitivity / ε.
DP-SGD recipe: clip per-example gradient norm to C, add Gaussian noise N(0,σ^2 C^2 I), and use a privacy accountant (Moments/FFT accountant) to compute final (ε,δ). Expect utility loss: strict ε (≈0.1) degrades accuracy; ε≈1 is moderate.
Membership & inversion attacks: attackers infer whether an example was in training (membership) or reconstruct features (inversion). Mitigations: reduce output granularity (no raw confidences), add output noise, use DP training, remove near-duplicates, strong regularization and early stopping.
Output sanitization patterns: return top-k labels instead of probabilities, apply temperature scaling or additive noise to logits, clamp rare-feature outputs; these reduce leakage but can hurt UX/utility—quantify impact via offline utility tests.
Testing and auditing heuristics: sanity checks include training on random labels (high AUC indicates leakage), feature permutation importance pre/post split, shadow-model membership-inference experiments, and replaying serving logs through the training pipeline to detect mismatches.
Operational controls an MLE owns: deterministic feature pipelines, feature version tags, unit tests that assert no feature uses future timestamps, privacy-aware model cards documenting expected ε (if DP used) and known tradeoffs.
Limits and scale considerations: DP methods need many samples for good utility; DP for models trained on <100k sensitive examples often yields poor accuracy at meaningful ε. For large datasets (millions), DP becomes practical but still reduces fine-grained personalization.

Worked example — "Detecting and fixing data leakage between training and serving for a personalized recommender"

First 30s clarifying questions: what are the feature sources and their timestamps, is there a `feature-store` or ad-hoc ETL, what exact label and labeling window are used, and how are users split (per-user or per-event)? A strong answer organizes around three pillars: (1) diagnose (duplicate detection, timestamp consistency, out-of-fold label checks), (2) mitigate (user-level/time-based splits, snapshot features, out-of-fold encodings), and (3) validate & monitor (retrainable holdout, replay logs, automated unit tests). Example actions: compute hashes of preprocessed rows to detect identical examples across splits, rebuild features from historical snapshots to ensure no future joins, and change target-encoding to out-of-fold with smoothing. Key tradeoff to call out: moving to coarser temporal features or stricter splitting reduces apparent model accuracy but prevents unrealistic online performance. Close by proposing ongoing controls: CI tests that assert no features use post-label timestamps, a cold holdout not touched during development, and a plan to measure online/offline parity after fixes.

A second angle — "Mitigating membership inference attacks on a production ranking model"

Same conceptual toolkit applies but the attacker model differs: here the adversary queries the serving API. Start by measuring vulnerability with shadow models and standard membership-inference attackers to estimate attack success rate. Mitigations you’d implement as an MLE include retraining with `DP-SGD` for a target (ε,δ), lowering output fidelity (drop confidences or return coarse scores), and pruning or deduping memorized examples in the training set. Emphasize experimental evaluation: quantify utility loss vs. reduction in attack AUC, and run A/B tests to ensure ranking quality remains acceptable. Note operations that are not solely an MLE responsibility—rate-limiting and API throttling—must be coordinated with infra/security, but the MLE must supply concrete thresholds and measures.

Common pitfalls

Pitfall: Assuming high validation AUC always signals good model quality rather than possible leakage.
If you see unexpectedly high offline metrics, first check for duplicates, user-level leakage, or feature computed from future timestamps before celebrating performance.

Pitfall: Citing "use DP" without detailing the implementation costs.
Interviewers expect specifics: per-example gradient clipping, noise scale, accountant choice, and an estimate of expected Δ in metric. Saying "we can add DP" without numbers is shallow.

Pitfall: Over-relying on infra/security to solve leakage.
MLEs must own reproducible training pipelines, feature-versioning, and offline tests. Saying "we'll rely on network rate-limits" misses the engineering responsibility to design model-side sanitization and auditability.

Connections

Interviewers often pivot to feature-store design & versioning, model monitoring and drift detection (how you detect that a new batch causes higher leakage), or A/B testing design to validate privacy mitigations' impact on business metrics. Be prepared to bridge into the security/infra teams with specific measurement-based requests.