Engineer and Impute ZIP Features
Company: Intuit
Role: Data Scientist
Category: Machine Learning
Difficulty: medium
Interview Round: Technical Screen
##### Question
You are building a predictive model for a product team. For some users you have address fields such as street, city, state, and ZIP code. Many records include a ZIP code, but some do not. You may also join external public data, such as census-style demographic summaries, using ZIP code or geography.
Assume the prediction target is not specified; answer in a general way that would be appropriate for a product-focused data science interview.
1. What address-derived or ZIP-linked features would you consider using as model inputs? What external public datasets could you join on ZIP code or geography to create additional features?
2. How would you encode geographic fields, especially high-cardinality ZIP codes?
3. How would you handle missing ZIP codes? Discuss when to drop vs. impute, hierarchical fallbacks, and missingness as a potentially informative signal.
4. What risks would you watch for when using geographic and demographic variables (fairness, privacy, leakage, overfitting, staleness)?
5. How would you evaluate whether these features actually improve the model?
Overview: This Intuit data scientist machine learning screen evaluates feature engineering from address/ZIP data, joining external census-style datasets, high-cardinality encoding, and missing-ZIP imputation. It also tests awareness of fairness, privacy, leakage, and how to validate whether geographic features actually improve a model.
Community answers
Answer by hugox
1a. address-drived city, region, state, country infor; rural/urban, lat/long
1b. US Census Bureau survey (ACS), IRS stats of income, zillow, BLS
ZIP3, entity embedding map to lower-dimensional space,
based on other address fields, missing flag (due to privacy concern)
all of these
compare models with vs w/o zip features offline & online, check feature importance