Make the contract machine checkable. Keep a schema, an OpenAPI document or protobuf definitions, generated from or validated against the code, and run a compatibility check in CI that fails on a breaking change such as a removed field or a tightened type. Add consumer driven contract tests for internal clients, and version events the same way you version endpoints.
Why interviewers ask this
The interviewer wants to know whether compatibility is enforced by tooling or by hoping people notice. They are listening for a schema in version control, an automated diff gate, and how you cover message payloads as well as HTTP. It also touches on organizational reality: how you learn who actually consumes an endpoint before you change it.
How to structure your answer
- Put the contract in version control and keep it in sync with the code.
- Add an automated compatibility diff as a CI gate.
- Cover internal consumers with contract tests.
- Explain how you find real consumers before changing anything.
Example answer
The contract has to be a file that CI can compare, otherwise compatibility depends on whoever reviews the pull request. So the OpenAPI document lives in the repository and is generated from the handlers, which stops it drifting into fiction, and there is a job that diffs it against the version on the main branch and fails on anything breaking: a removed field, a new required parameter, a narrowed type. Adding things is always allowed. For internal consumers I like consumer driven contracts, where each client publishes the subset it actually relies on and my build verifies I still satisfy all of them, so I find out at build time rather than from their on call. Events get the same treatment through a schema registry with a compatibility mode set, since a broken event payload is worse than a broken endpoint because consumers fail asynchronously. And before changing anything I check the per client request metrics, because the contract tells me what is possible and the metrics tell me who would actually notice.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- What counts as a breaking change in a JSON response?
- How would you handle a client that depends on undocumented behavior?
- How do you manage schema evolution for events over years?
Related backend developer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions