All jobs / Data science / ML / AI

Feature Engineering interview questions

Feature Engineering questions a Data science / ML / AI can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. A feature is “hours-to-churn.” The model looks perfect. What happened?

    The strongest answer: That number is computed from the outcome — it is not knowable at prediction time. Drop it and rebuild

    Why it works: Exactly. If you need the future to compute the feature, it is not a feature. It is the label in a costume.

    • Ask: would I have this at score time?
    • Outcome-derived columns are leakage.
    • Importance does not excuse a leak.
    • Do not save leakage for prod.

  2. You have a “country” column and a “T-shirt size” column. How do you encode each for a model, and why not the same way?

    The strongest answer: Country has no order, so one-hot (or a target or hashing encoding if there are hundreds of values); size is ordered small–medium–large, so integer codes that preserve the order are fine and keep the column narrow

    Why it works: Exactly — encoding should mirror the meaning: nominal gets independent columns, ordinal gets ordered codes.

    • Encode what the column means.
    • Nominal: one-hot or target encoding.
    • Ordinal: ordered integer codes.
    • Fake orders mislead linear models.

  3. Someone concatenated train and test “just to fit the scaler.” What is wrong?

    The strongest answer: The scaler now saw test distributions — that is leakage. Fit transforms on train only, then apply

    Why it works: Exactly. Any statistic computed with test rows in the room has peeked.

    • Fit preprocessors on train only.
    • Apply them to val/test.
    • Unsupervised peek is still a peek.
    • Do not “just” include test.

  4. 30% of income is missing. First move?

    The strongest answer: Ask why it is missing — refuse, not collected, system drop — then choose a treatment that matches; I do not silently median-fill and move on

    Why it works: Exactly. Missingness can be the signal. Silent fill invents people.

    • Diagnose why values are missing.
    • Treat missingness on purpose.
    • Do not silent-fill.
    • Dropping rows can bias who remains.

  5. “days_since_last_complaint” is missing for people who never complained, and those rows are all non-churn. What is the leak risk?

    The strongest answer: Missingness is a near-copy of the label — I treat it as a suspect, model it honestly, or drop the cheat; I do not call it a clever feature

    Why it works: Exactly. A feature that exists only because of the outcome is leakage. Name it.

    • If missingness copies the label, suspect leak.
    • Do not celebrate a cheat feature.
    • Fills can amplify the leak.
    • Do not drop one class to tidy it.

  6. A column is named `will_renew_next_quarter` in a “features” table. Your move?

    The strongest answer: Treat it as a label until proven otherwise — check lineage and when it is written — then remove it from features if it is the outcome

    Why it works: Exactly. Names lie. Lineage and write-time tell you if it is the target.

    • Lineage over column names.
    • Outcomes are not features.
    • Warehouse ≠ allowed.
    • Do not train on the label in costume.

  7. A join to “customer_value” includes a field updated after the churn date. What do you do?

    The strongest answer: Point-in-time join — values as of the decision timestamp — or drop the field. A late update is leakage

    Why it works: Exactly. As-of the decision. Latest is a time machine.

    • Point-in-time features only.
    • Latest-after-label is leakage.
    • Averages can still leak the future.
    • Disclaimers do not un-leak.

  8. You fit a PCA on train+val+test “because PCA is unsupervised.” Response?

    The strongest answer: Unsupervised still estimates a structure from those rows — fit on train (or a nested inner set), then project. Test rows do not get a vote

    Why it works: Exactly. The components are a function of who was in the room.

    • Fit reductions on train only.
    • Unsupervised can still leak.
    • Row count does not excuse a peek.
    • Do not fit on test.

  9. You embed tickets with a model trained on your own historical tickets, including future resolutions. Risk?

    The strongest answer: The embedding space can carry tomorrow’s language — I treat in-house embedders like any other fit: time-safe data only

    Why it works: Exactly. Learned representations remember their training stories. Time-safety applies.

    • In-house embedders need time-safe training.
    • Representations can carry future language.
    • Normalise ≠ de-leak.
    • Dimension is not a cleanse.

  10. You inherit a credit model with 3,000 features nobody can list from memory. The team wants to add 500 more from a new vendor feed before the next retrain.

    What rule do you set for feature selection, and what do you refuse?

    The strongest answer: Every kept feature has an owner, a freshness contract and a measured contribution; selection runs inside the cross-validation folds, never on the test set; nothing ships that serving cannot reproduce

    Why it works: Right — at this scale selection is governance: leakage review, cost, drift surface and serving parity, done inside the folds so the estimate stays honest.

    • Selection is governance at scale.
    • Select inside the CV folds.
    • Every feature has an owner.
    • Refuse what serving cannot reproduce.