How would you implement versioning for feature definitions in a feature store?

WHAT THIS TESTS: This question probes your ability to design a versioning system that separates metadata schema evolution from data state history in a feature store. The interviewer wants to see if you understand that reproducibility requires pinning both the schema and the data that was used to train a specific model, not just one or the other. They are also checking whether you can distinguish breaking from non-breaking changes and apply the right versioning semantics to each.

A GOOD ANSWER COVERS: A strong response starts by defining two independent dimensions: metadata versioning and data versioning. For metadata, explain that every feature group or feature definition should carry an explicit version number. Breaking changes such as removing a feature, renaming a column, or altering the computation logic must trigger a new immutable schema version so existing pipelines continue to point to the old definition. Non-breaking additions like appending a new feature should be handled through safe appends that attach default values as metadata without rewriting existing data. For data versioning, the answer should mention commit-based snapshots or as-of queries so that a training dataset can be reconstructed from the exact historical state of the feature group. Finally, emphasize that training pipelines must pin both the schema version and the data timestamp or commit ID rather than resolving a floating latest alias.

COMMON WRONG ANSWERS: A major red flag is proposing in-place schema mutations where a feature group is updated directly and all consumers automatically see the change. Another weak pattern is relying on a mutable latest tag or defaulting to the most recent version without explicit pins, which silently breaks model reproducibility the moment the schema changes. Candidates also err by treating data versioning as optional or assuming that timestamp columns alone are sufficient without atomic commit boundaries or backfill guarantees.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle backfilling a newly appended feature across historical data without corrupting prior versions. They might also probe the storage and query cost implications of keeping multiple schema versions and commit snapshots, or ask how you would enforce version pinning across a large organization where many teams share the same feature store.

ONE CONCRETE EXAMPLE: Imagine a user_engagement feature group at version 1 containing session_count and click_rate. The team decides to replace click_rate with a new weighted_click_rate computed differently. This is a breaking change, so they create version 2 of the feature group with the new schema. Existing production models continue to request version 1, preserving their behavior. Meanwhile, a data scientist appends a new feature called device_type to version 2 using a safe append with a default value of unknown. Old rows are not rewritten; the default is stored as metadata and applied at query time. When a model is trained six months later, the training pipeline specifies user_engagement version 2 as of commit ID abc123, guaranteeing that the exact same rows and schema can be reproduced for audit or rollback.