Engineer and Impute ZIP Features

Question

Suppose you are putting together a predictive model for a product team. For certain users you hold address information such as street, city, state, and ZIP code. A large share of the records carry a ZIP code, though some do not. You are also free to bring in outside public data, for instance census-type demographic aggregates, keyed on ZIP code or geography. Take the prediction target as unspecified; respond in a broad manner that would suit a product-oriented data science interview.

1. Which features derived from addresses or linked to ZIP codes would you consider as model inputs? Which external public datasets could you join on ZIP code or geography to build extra features?
2. How would you encode geographic fields, particularly ZIP codes with high cardinality?
3. How would you deal with missing ZIP codes? Cover when to drop versus impute, fallbacks through a hierarchy, and missingness as a signal that may carry information.
4. Which risks would you keep an eye on when geographic and demographic variables are used (fairness, privacy, leakage, overfitting, staleness)?
5. How would you assess whether these features genuinely make the model better?

Overview: This data scientist machine learning screen covers feature engineering from address and ZIP data, joining outside census-style datasets, encoding high-cardinality fields, and imputing missing ZIP codes. It also checks awareness of fairness, privacy, leakage, and how to confirm that geographic features truly lift a model.

Community answers Answer by hugox 1a. city, region, state, country derived from address; rural versus urban; latitude/longitude 1b. US Census Bureau surveys (ACS), IRS income statistics, Zillow, BLS ZIP3, entity embeddings mapping into a lower-dimensional space, using the other address fields, a missing indicator (for privacy reasons) all of the above compare models with and without ZIP features offline and online, inspect feature importance