An interviewer says - we have about 30 models in production at a short-video platform at ByteDance scale and every team trains and deploys its own way. What do you centralise first, and what do you deliberately leave alone?

What the interviewer is testing

Whether you centralise by failure mode rather than by category. A candidate who answers "build a platform covering training, serving, features, monitoring and governance" has described a two-year programme and prioritised nothing. The expected answer picks the two or three things whose inconsistency actually causes incidents, and names what is better left to teams.

The clarifying questions that change the answer

• What has actually gone wrong in the last year? Training-serving skew, a model that silently degraded, an incident nobody could roll back, a compliance finding. The answer picks the first thing to centralise.
• How many of the 30 models are customer-facing and reversible? A ranking model with a shadow mode and a fraud model that declines payments need different controls.
• Is there a regulatory obligation - model documentation, bias testing, explainability? If so, the evidence layer is centralised first regardless of engineering preference.
• How large are the teams? Five teams of eight will adopt a shared path; thirty teams of two need the path to be the default or it will not be used.

What a strong answer centralises first

1. Feature computation, or at least feature definitions. Training-serving skew is the most common cause of "good in evaluation, bad in production", and it is structural: two code paths computing the same feature will diverge. One definition used by both paths removes a whole class of defect, and nothing a team builds locally can substitute for it.
2. The inference record. Every prediction logged with model version, feature values or their hash, the input identifier and the output, to a common schema. This is the substrate for everything else - monitoring, debugging, bias analysis, incident reconstruction, retraining data - and it is cheap. A team that logs predictions in its own format can never be included in a cross-cutting investigation.
3. Rollback as a platform capability. A model version pointer that can be moved in minutes, with the previous version warm. Most organisations can deploy a model faster than they can withdraw one, which is the wrong way round.

What a strong answer deliberately leaves alone

• Training frameworks and model architectures. Centralising these buys consistency nobody benefits from and costs the thing teams care most about; it is also the fastest way to make the platform resented.
• Notebooks and the experimentation loop. Standardising exploration slows the only part of the work that is supposed to be cheap and disposable.
• Evaluation metrics per model. The shared requirement is that evaluation results are recorded in a common place, not that a ranking model and a fraud model share a metric.

Common weak answers

• "Build a feature store" as a product rather than as the answer to skew, with no statement of which incident it prevents.
• "Standardise on one framework." High cost, low benefit, maximum resistance.
• "Add monitoring to all 30 models." Monitoring on inconsistent prediction logs produces 30 bespoke dashboards and no cross-cutting view - the inference record comes first.
• "Centralise everything, with a platform team as a gate." Creates a queue, and teams route around a queue.

What a strong answer adds

The adoption mechanism and the cost. A platform that is optional and better wins; a platform that is mandatory and slower gets bypassed, so migrate the two highest-volume models first as proof, publish the time-to-first-prediction for the paved path, and keep an exit. And name the price: a shared feature definition means a change to it affects several models at once, so the platform now needs versioning and a deprecation process of its own - which is a real cost, not a detail, and it is the reason teams resist centralisation that arrives without it.