How would you design safe, automatic schema evolution in CI?

WHAT THIS TESTS: This question evaluates whether you can distinguish between a data quality failure and a legitimate schema evolution event, and whether you design systems that treat schema changes as first-class concerns rather than emergencies. The interviewer wants to see producer-consumer contract thinking, backward compatibility discipline, and operational safety in ML pipelines. They are looking for an architecture that reduces toil while preventing silent model corruption.

A GOOD ANSWER COVERS: First, establish versioned data contracts between upstream producers and the ML pipeline, using a schema registry that classifies changes as safe, risky, or breaking. An additive enum value should be backward compatible and auto-approved by the contract, preventing an unnecessary CI failure. Second, separate structural schema validation from semantic ML validation. The CI gate should check conformance to the contract, not a frozen snapshot of allowed values. Third, implement model-side resilience for unknown categories, such as an explicit unknown bucket in a categorical encoder, a hash-based embedding strategy, or a default index in a vocabulary lookup so that serving does not crash when a new value arrives. Fourth, automate downstream reactions rather than blocking the pipeline. When a new category is detected, the system should log it, alert the owner, and trigger a retraining job only after the category crosses a frequency or business-impact threshold. Fifth, ensure the producer is aware of downstream consumers by making the contract API-driven, so the upstream service cannot accidentally publish a breaking change without violating the contract.

COMMON WRONG ANSWERS: A major red flag is suggesting a manual ticket or allow-list for every new category, which does not scale and contradicts the goal of minimizing manual intervention. Another red flag is disabling validation entirely or switching to loose typing, which invites silent data corruption and training-serving skew. Candidates also stumble by conflating schema evolution with data bugs, proposing to reject the new category as invalid rather than evolving the system to accommodate business growth. Finally, hard-coding categories in a Python module or JSON config without a registry means every upstream change requires a code deployment downstream.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle a breaking schema change such as a renamed column or a dropped feature. They might also probe how you prevent training-serving skew when the training data contains the old vocabulary and serving sees the new category. Another follow-up is how you enforce semantic contracts, for example ensuring that a new category does not cause a sudden distribution shift that degrades model performance. You should also be ready to discuss rollback strategy if an auto-approved additive change still causes an unexpected production issue.

ONE CONCRETE EXAMPLE: Imagine a shipment_status feature with values like pending, in_transit, and delivered. The business adds delayed. Without contracts, the data validation step fails because delayed is not in the hard-coded enum. With the proposed design, the upstream service publishes a new schema version adding delayed to the contract as a backward-compatible change. The schema registry auto-approves it. The CI pipeline validates that the incoming data matches the contract, sees the new value is allowed, and passes. The model encodes delayed into the unknown bucket initially, so inference continues safely. An alert fires because a new contract field appeared, and after delayed reaches five percent of daily volume, an automated retraining pipeline starts, rebuilds the vocabulary, and deploys a new model that recognizes delayed natively.

Source: mlops.community - An Engineer's Guide to Data Contracts – Pt. 1