Feature Engineering Interview Questions

Sample Answer

Yes, you should scale the continuous features, typically to zero mean and unit variance, and leave the binary flag as 0 or 1. With L2, the penalty is on coefficients, so unscaled features force the model to use tiny weights for large magnitude inputs and larger weights for small magnitude inputs, which changes the effective regularization strength per feature. After scaling, the regularizer treats features more comparably, so coefficient shrinkage is more uniform and feature importance comparisons are more meaningful. You also get better conditioning for gradient based solvers and faster, more stable convergence.

Sample Answer

You could leave it and rely on trees to be mostly scale invariant, or you could clip and transform to reduce the damage from glitch driven splits. Clipping at a high percentile wins here because a few extreme spikes can create unhelpful early splits and brittle thresholds, especially if the spikes correlate with missingness or device types. For a neural net, scaling and possibly a log transform matter more because optimization is sensitive to feature magnitude and outliers can blow up activations and gradients. In both cases, you should set clip values using training data only, and verify by time based validation and drift monitoring of the clipped fraction.

Sample Answer

First, you decide whether missingness itself is signal, here it likely is, so you add a missing indicator feature $m = \mathbb{1}[x \text{ is missing}]$. Next, you impute $x$ using a training only statistic, median is a good default for heavy tails, and you compute that statistic within each training fold to avoid leakage. Then you scale the imputed numeric feature if you are using a linear model or a neural net, but you can often skip scaling for trees. Finally, you sanity check that the indicator is not proxying for a label leak by validating on a later time window and by inspecting performance broken down by reporting vs non reporting partners.

Sample Answer

You could do one hot encoding or target encoding. One hot is safe but will be extremely sparse and mostly useless for rare restaurants unless you have massive data and strong regularization. Target encoding wins here because it can share statistical strength, but only if you compute it with out of fold estimates and smoothing like $$\text{TE}(c)=\frac{n_c\mu_c+m\mu}{n_c+m}$$ so low count restaurants shrink toward the global mean. You also need time based splits if the label is time dependent, otherwise you leak future outcomes into past rows.

Sample Answer

First, you separate low cardinality from high cardinality because the scaling behavior is different. Color has 30 values, so one hot fits easily and gives the model clean, interpretable signals. Brand has 50k values, so one hot will blow the budget, you either hash it into a fixed number of buckets or keep top $K$ brands as one hot and map the rest to an OTHER bucket. Then you validate the tradeoff by checking collision rate for hashing, offline metrics, and that unseen brands at serving time map deterministically to a bucket or OTHER.

Sample Answer

This question is checking whether you can keep categorical features reproducible and robust when the category set changes between training and serving. You should choose an encoding that has a defined behavior for unknowns, for example an explicit UNK token for one hot, or hashing for high cardinality features so new values still map into the same space. You need to freeze and version the vocabulary or hashing config with the model artifact, and enforce the same preprocessing code path offline and online. Finally, you add monitoring for unknown rate, top category drift, and feature nulls so you catch schema shifts before metrics degrade.

Sample Answer

Start by defining label_time as request_time + 24h, and define the label as 1 if host_response_time exists and host_response_time <= label_time. For each training row keyed by (host_id, request_id), you compute features using only events with event_time < request_time, not < label_time, because anything after the request is not known at decision time. Then your 3-day window is $$[request\_time - 72h,\; request\_time)$$ and you aggregate messages in that half-open interval. Finally, you ensure the same cutoff is used in inference, so the feature generator takes a request_time and never scans beyond it.

Sample Answer

This question is checking whether you can separate the user-observed timeline from the pipeline-observed timeline and still keep train serve consistency. You should compute recency using click_time relative to the impression_time (your decision time), with a strict cutoff click_time < impression_time so you never use the click on the item you are ranking. For reproducibility with late logs, you also pin a snapshot, for example only include clicks whose log_time <= snapshot_time, and you generate both labels and features from that same snapshot. That way the feature is time-correct (click_time) and dataset-stable (snapshot on log_time).

Sample Answer

The standard move is to build the feature using a trailing window that ends at the feature_date start, for example for day $D$ use sessions in $$[D-28,\; D)$$ so you never include any part of day $D$. But here, backfills matter because if you allow late-arriving sessions to update past days, your historical feature values will drift unless you freeze them by snapshot or watermark. If you must backfill, the exception is you need a clear recomputation policy, like recompute the last 7 days only, and keep older days immutable, or train on the same recomputation policy. Otherwise your offline training rows will not match what the model would have seen on that day in production.

Sample Answer

This question is checking whether you can keep features stable under drift while still learning new language. You typically use a hashing vectorizer for the core sparse features so the feature space is fixed, then optionally add a small, curated vocabulary for top terms with explicit indices for interpretability. You monitor OOV rate, hash collision rates, and distribution shift metrics like PSI on key aggregates, then trigger retraining or recalibration when thresholds are crossed. If you must use learned vocab, you version it and run a shadow evaluation to ensure new vocab does not change the meaning of existing indices.

Sample Answer

The standard move is to start with language-agnostic features, character $n$-grams with hashing, plus a lightweight language ID feature and basic text stats, because they work across scripts and do not require perfect tokenization. But here, multilingual normalization matters because inconsistent Unicode forms, diacritics handling, and punctuation can create silent train serve mismatch. You define a single normalization contract: Unicode NFKC, canonical whitespace, and a clear policy on lowercasing and accent folding per language, then you test it with golden strings across languages. If you later add embeddings, you prefer a single multilingual encoder and keep the char $n$-gram baseline to cover rare languages and novel slang.

Sample Answer

Get this wrong in production and your model silently degrades because the online text path tokenizes differently, truncates differently, or uses a different embedding model version than offline. The right call is to define one canonical text preprocessing and embedding service, version it, and reuse it for both offline backfills and online inference, with explicit truncation rules like first $N$ characters after normalization. Cache embeddings keyed by content ID and model version, and set a strict timeout, then fall back to sparse hashed features or cached stale embeddings when the service is slow. You also log both the raw text hash and the embedding version so you can audit skew and roll back quickly.

Sample Answer

The standard move is to propose a simplification via stepwise ablation, drop candidates in groups, and keep only features that deliver measurable lift on a held out time split and key slices. But here, SHAP can be misleading because correlated features can share or steal attribution, and leakage can make one feature look dominant. You should confirm with permutation importance, ablations, and a leakage audit, for example verify the feature timestamp precedes the label window. Finally, check if smaller features improve tail slices like new users, low activity users, or specific locales, since global SHAP can hide slice critical signal.

Sample Answer

Get this wrong in production and you either block good users in that country or you let fraud through, both are expensive and hard to unwind. The right call is to run slice based error analysis on that country and Android, compare score distributions, calibration, and false positive rate, then quantify drift for the fingerprint feature with PSI or KL, and check missingness and cardinality changes. Do targeted ablations on that slice, remove the feature, bucket it, or replace it with a more stable proxy, and measure the delta on both global and slice metrics. If the feature is unstable but valuable elsewhere, gate it by platform or confidence, add monitoring, and backfill a safer version before fully re enabling.

Sample Answer

Dropping the feature with the smaller coefficient sounds reasonable but breaks under multicollinearity, the sign and magnitude are not stable or interpretable. Relying on SHAP to pick a winner does not work because attribution can arbitrarily split across correlated inputs depending on the background distribution. That leaves grouped reasoning and refactoring: treat them as a feature group, evaluate ablations at the group level, then replace both with a single engineered feature like discount rate $$r = 1 - \frac{\text{discounted\_price}}{\text{price}}$$ plus one absolute price measure. You then re run time split validation and confirm that importance and coefficients stabilize, and that business interpretation aligns with the refactor.