Feature Engineering for ML Interviews — Encoding, Scaling, and Leakage Avoidance

Feature engineering for ML interviews is not about listing every transformation you know. The interviewer is usually testing whether you can turn messy product data into model-ready signals while avoiding encoding mistakes, scaling errors, and leakage. A strong answer sounds practical: clarify the prediction point, define what data is available at that moment, build a reproducible preprocessing pipeline, and justify why each feature helps the model generalize instead of memorize.

Feature engineering for ML interviews: the interviewer's real signal

When a machine learning interview includes feature engineering, the expected answer is less "use one-hot encoding" and more "I understand the boundary between raw business events and valid training examples." The interviewer wants to hear how you reason about:

• Prediction target: What exactly are we predicting, and at what time?
• Training row: What does one row represent: user, session, transaction, document, account, or time window?
• Available information: Which attributes are known before the prediction and which are only known afterward?
• Model family: Linear models, tree models, neural models, and nearest-neighbor methods need different preprocessing.
• Evaluation setup: Features must be fit inside the training folds, not on the full dataset.

A useful opening answer is: "Before choosing encodings, I would define the prediction timestamp and the evaluation split. Then I would separate numeric, categorical, text, time, and aggregate features, and make sure every transformation is learned only from training data." That sentence alone signals senior judgment.

Start with a feature inventory

In interviews, slow down for one minute and inventory the raw data. A simple table makes your answer concrete.

| Raw field type | Example | Feature ideas | Risks | |---|---|---|---| | Numeric | price, age, balance | clipping, log transform, z-score, bins | outliers, drift, unit changes | | Categorical | country, device, plan | one-hot, target encoding, frequency encoding | high cardinality, unseen values | | Time | signup date, event timestamp | recency, day of week, tenure, rolling windows | future leakage, timezone bugs | | Text | search query, support ticket | n-grams, embeddings, length, sentiment proxy | sparse features, PII, vocabulary leakage | | Aggregates | purchases last 30 days | counts, rates, ratios, rolling means | using data after prediction time | | Interactions | price × discount, plan × region | crossed features, ratios | overfitting, explainability loss |

This inventory helps you avoid jumping into transformations before you know the modeling problem. It also creates natural follow-up points: "For a tree-based model I may not need to scale numeric features, but for logistic regression or neural nets I would. For high-cardinality categorical variables I would avoid naive one-hot if it explodes dimensionality."

Encoding categorical variables without hand-waving

Encoding is the most common feature-engineering interview topic because it exposes tradeoff thinking. Use the category cardinality and model type to choose.

One-hot encoding is the default for low-cardinality nominal variables such as browser, plan tier, or payment method. It is easy to explain and works well for linear models. The downside is dimensionality: a field with 50,000 merchant IDs becomes a huge sparse matrix, and rare levels may not get enough examples.

Ordinal encoding is appropriate only when the order is meaningful: education level, risk band, product tier. It is risky for nominal categories because the model may infer fake distance between categories. Encoding "red=1, blue=2, green=3" tells many models that green is greater than red, which is nonsense.

Frequency or count encoding replaces a category with how often it appears in training data. This is useful for high-cardinality categories where popularity itself is predictive: merchant frequency, user agent frequency, city frequency. It should be computed on training data only and should handle unseen categories with a default.

Target encoding replaces a category with the historical average target for that category. It can be powerful for high-cardinality fields, but it is one of the easiest ways to leak. The safe interview answer is: "I would use out-of-fold target encoding with smoothing, so each training row's encoding is computed without using that row's label, and I would compute validation/test encodings from the training fold only." Mention smoothing toward the global mean for rare categories.

Hashing trick maps categories into a fixed number of buckets. It is useful when the vocabulary is huge or streaming, and you cannot maintain a full dictionary. The tradeoff is collisions and lower interpretability.

Embeddings are appropriate when categories have many levels and rich co-occurrence structure, such as products, ads, or users. They require more data and are usually learned as part of a neural model or pretraining step, so do not overclaim them for small tabular problems.

A compact decision rule: low-cardinality nominal -> one-hot; ordered categories -> ordinal; high-cardinality with enough data -> target/frequency/hash; learned representation problems -> embeddings.

Scaling, transformations, and when they matter

Scaling is not universally required. A senior answer connects scaling to the model's objective.

• Linear/logistic regression, SVMs, kNN, k-means, PCA, and neural networks: scaling usually matters because coefficients, distances, gradients, or variance directions are affected by feature magnitude.
• Decision trees, random forests, and gradient-boosted trees: monotonic scaling is usually not necessary because splits depend on thresholds, not distance. Outliers and binning can still matter.
• Regularized models: scaling is important because L1/L2 penalties are applied to coefficients; unscaled features distort the penalty.

Choose the transformation based on distribution:

| Problem | Transformation | Interview explanation | |---|---|---| | Roughly normal numeric feature | StandardScaler | Centers mean and scales variance for gradient-based models | | Bounded range needed | MinMaxScaler | Useful for neural nets or distance models when bounds are stable | | Heavy outliers | RobustScaler or winsorization | Uses median/IQR or caps extremes so outliers do not dominate | | Long-tailed positive values | log1p | Turns multiplicative differences into additive differences | | Nonlinear thresholds | bins/quantiles | Makes effects easier for linear models, but can lose detail |

The critical phrase: "Fit the scaler on training data only, then apply the learned parameters to validation and test." If you compute mean and standard deviation on all rows, validation data influences training preprocessing. That is a subtle but real leakage bug.

Leakage avoidance: the part that wins the interview

Leakage happens when a feature contains information that would not be available at prediction time or lets labels bleed into training transformations. Interviewers love leakage because it separates people who have shipped models from people who have only notebooks.

Common leakage patterns:

1. Future data: Predicting churn on March 1 using "support tickets in March" or "last payment status after renewal." The feature is real but unavailable at decision time.
2. Post-outcome fields: Predicting fraud using chargeback reason, manual review outcome, refund status, or cancellation timestamp.
3. Global preprocessing: Scaling, imputation, vocabulary building, PCA, or feature selection fit on the full dataset before train/test split.
4. Target encoding leakage: Encoding a merchant with its average fraud rate using the same row's label.
5. Cross-validation leakage: Duplicates, same user, same household, or same company appearing in both train and validation folds.
6. Time leakage in aggregates: Computing "transactions in last 30 days" from a table snapshot that already includes future events.

A strong rule: every feature should be expressible as a query with WHERE event_time <= prediction_time. For time-series or product-event models, say that out loud. It shows you think in production terms.

Example answer: churn prediction feature plan

Suppose the interviewer asks: "Design features for a subscription churn model." A strong answer could be:

"I would define the prediction point as seven days before renewal and the label as whether the account cancels within the next 30 days. Each row is an account-renewal opportunity. I would use only data available before that prediction timestamp. Numeric features would include tenure, seats, monthly spend, days since last login, number of active users, and support ticket count in the trailing 7/30/90 days. Categorical features would include plan tier, acquisition channel, region, and billing cadence. For low-cardinality categories I would use one-hot encoding. For account owner or industry, if high-cardinality, I might use smoothed frequency or target encoding computed out-of-fold. I would log-transform long-tailed counts like event volume and scale numeric features if using logistic regression. I would split by time, not randomly, because churn behavior drifts and future cohorts should not inform past predictions."

Then add the trap: "I would avoid features like cancellation survey response, refund issued, or support outcome after renewal, because those leak the result."

That answer is concrete, scoped, and leakage-aware.

A reusable interview framework

Use this five-step framework when you feel stuck:

1. Define the row and timestamp. What is one training example and when is the prediction made?
2. List raw inputs by type. Numeric, categorical, time, text, aggregates, interactions.
3. Pick transformations by model. Scaling for distance/gradient models; encoding by cardinality; bins or logs for skew.
4. Protect evaluation. Fit preprocessing in the training fold, use time/group splits if needed, and handle unseen values.
5. Explain productionization. Store feature definitions, monitor drift, and make online/offline computation consistent.

If you structure your answer this way, you can handle almost any feature-engineering prompt: fraud detection, recommendations, ranking, pricing, lead scoring, churn, credit risk, or search relevance.

Common traps and how to avoid them

Trap: treating all categorical variables the same. Say why one-hot is fine for ten plan tiers but not for millions of product IDs.

Trap: scaling tree inputs mechanically. Scaling is usually unnecessary for tree splits. It may be harmless, but saying "always scale" sounds memorized.

Trap: forgetting unseen categories. In production, new countries, devices, campaigns, and merchants appear. Your encoder needs an unknown bucket or hashing strategy.

Trap: random split for time-dependent problems. Random splits can overestimate performance when user behavior, campaigns, prices, or fraud tactics change over time.

Trap: feature selection before split. Selecting top features using all labels leaks validation information. Feature selection must be inside cross-validation.

Trap: aggregate windows without cutoffs. A trailing 30-day feature must be trailing relative to each row's prediction time, not relative to the export date.

How to talk about feature engineering on a resume

Resume bullets should connect features to model performance or business decisions without overclaiming. Good patterns:

• "Built leakage-safe churn features from product usage, billing, and support events using time-windowed aggregates and out-of-fold encodings."
• "Reduced offline-to-online skew by moving feature definitions into a shared pipeline with train-only fit parameters and production defaults for unseen categories."
• "Improved fraud model precision by replacing raw merchant IDs with smoothed frequency and target encodings validated through grouped cross-validation."

Avoid vague bullets like "performed feature engineering to improve ML model." Say what you transformed, what risk you handled, and why it mattered.

Prep checklist

Before an ML interview, practice explaining these quickly:

• One-hot vs ordinal vs target vs hashing vs embeddings.
• Which model families need scaling and why.
• How to fit scalers, imputers, encoders, and PCA without leakage.
• Why time splits and group splits matter.
• How to build trailing-window aggregates with a prediction timestamp.
• How to handle missing values, rare categories, and unseen categories.
• How to detect leakage when validation performance looks suspiciously high.

The best feature-engineering answers feel like production design, not a list of transformations. Define the decision time, choose encodings and scaling based on data and model behavior, and keep repeating the central rule: the model can only learn from information available when the prediction is made.

Related guides

• Classification Metrics for ML Interviews: Precision, Recall, ROC, and PR-AUC — A practical ML interview guide to classification metrics: how precision, recall, F1, ROC-AUC, PR-AUC, calibration, and thresholds work, and how to choose the right one for business tradeoffs.
• ML Evaluation Metrics for Interviews: Offline vs Online and Choosing the Right Metric — A senior-level guide to ML evaluation metrics in interviews: how to separate offline validation from online impact, pick metrics by task type, avoid leakage, and defend launch decisions.
• Big-O Complexity Cheatsheet for Coding Interviews 2026 — A no-fluff Big-O reference card covering every complexity class, data structure, and algorithm pattern you'll face in coding interviews.
• Caching Strategies for System Design Interviews: Write-Through, Write-Back, and TTL Patterns — The caching section of a FAANG system design loop is where mediocre candidates blur together. Here's how to name tradeoffs, pick a pattern on purpose, and survive the hot-key follow-up.
• Circuit Breaker Pattern in Interviews: Fault Tolerance and Graceful Degradation — The circuit breaker is the pattern most candidates name and none can actually configure. Here is how to talk about states, thresholds, and graceful degradation at staff level.