ML engineering round
Model Serving Prediction API Contract Coding Problem
Written and reviewed by Sahil Srivastav
What this interview round tests
A model is only as good as the service that serves it. The moment a model goes behind an API, the contract matters as much as the weights: the request schema clients send, the response schema they parse, and the validation that rejects bad input before it reaches the model. Get the contract wrong and every caller breaks, no matter how accurate the model.
Interviewers use this because productionising a model is the core of the ML engineering job. A serving endpoint with a mismatched schema returns fields clients do not expect, and one with no input validation passes malformed data straight into inference, where it fails in confusing ways.
The scenario
You are given a FastAPI service with a /predict endpoint and a pre-trained, pre-pickled trivial classifier already in the repo — the model is not the point. The request/response Pydantic schema does not match the intended contract, and invalid input is not rejected the way it should be.
The tests use FastAPI TestClient to assert status codes, response schema, and validation behaviour. Your job is to make the endpoint honour its contract: correct schema in and out, and clean rejection of bad input.
What you’ll practice
- Designing request/response schemas with Pydantic models
- Input validation and returning the right error status for bad input
- Matching a serving endpoint to the contract its clients depend on
- Testing an API with FastAPI TestClient
- Separating serving correctness from model quality
How to approach it
Pin down the contract first: what a valid request looks like, what a valid response must contain, and what should happen when the input is wrong. Then make the Pydantic models express exactly that, so valid requests deserialize and invalid ones are rejected with the appropriate status before they ever reach the model.
The classifier is deliberately trivial and fixed — every failing test is about the contract, not the prediction, so treat the TestClient assertions as the specification of the API.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
Do I need to train a model for this?
No. A trivial classifier is already pickled in the repo. The problem is entirely about the serving contract — schema, validation, status codes — which is where real serving bugs live.
Why does the serving contract get its own interview problem?
Because most model failures in production are integration failures, not modelling failures. An endpoint whose schema drifts from its clients, or that accepts malformed input, breaks the whole system regardless of how good the model is.