Concept questionMedium~7 minIntegration & Data / 7 of 7

Interview question

How would you test that an API change remains compatible with its consumers?

Test API contracts and compatibility

Combines schema diffing, real provider tests, consumer expectations, generated clients, semantic scenarios, and rollout evidence to prevent accidental API breaks.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I publish the API contract from the actual build and compare it with the supported baseline. CI flags removed operations or fields, new required input, type and nullability changes, enum changes, and altered responses. Provider integration tests then call the real HTTP pipeline and verify important status codes, headers, content types, and response examples. Additive optional fields are normally allowed; intentional breaks require an explicit migration or version decision.

Full answer below

Practice focus

OpenAPI checks, schema compatibility, consumer contracts, additive changes, versioning, and deployment order.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A schema catches structural changes, but compatibility also includes runtime serialization, headers, errors, defaults, ordering, and behavior that a client depends on. The test strategy needs both machine-readable contracts and representative use.
I publish the API contract from the actual build and compare it with the supported baseline. CI flags removed operations or fields, new required input, type and nullability changes, enum changes, and altered responses. Provider integration tests then call the real HTTP pipeline and verify important status codes, headers, content types, and response examples. Additive optional fields are normally allowed; intentional breaks require an explicit migration or version decision.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Schema comparison is necessary but not sufficient. Consumer-driven contracts capture assumptions such as a stable problem type, pagination cursor, default sort, or header that the provider schema may not express. I keep those contracts focused on behavior consumers truly need rather than mirroring every response byte. Representative generated clients are compiled and exercised against the new provider. Tests use tolerant readers for additive fields and include old request examples so narrowing accepted input is detected. Contract artifacts are versioned and tied to the deployable build, not regenerated later from a different environment.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I connect compatibility tests to rollout order and ownership. Providers remain able to serve old consumers while consumers tolerate additive responses; event and database contracts get the same overlap analysis when a release spans several components. A proposed break produces a reviewed diff that names affected consumers, migration sequence, support window, and rollback behavior. CI blocks unexplained baseline churn but provides an explicit approval path so teams do not normalize blindly updating snapshots. Synthetic checks and canary traffic verify routing, serialization, auth, errors, and headers after deployment, while version usage telemetry shows whether retirement criteria are actually met. I test semantic cases the schema cannot prove: enum fallbacks, omitted versus null, stable sorting, retry behavior, error identity, and changed defaults. Contracts are deleted when consumers retire so the suite remains useful rather than becoming an archive of unknown expectations. The goal is confidence that clients keep working, not maximum snapshot volume.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Updating the baseline automatically whenever CI reports a diff.
Testing mocked controller methods instead of the serialized HTTP boundary.
Copying the entire provider response into every consumer contract.
Checking structure while ignoring defaults, ordering, headers, and error meaning.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

No one knows which fields consumers rely on.
Contract files drift from real serialization.
Breaking diffs are routinely accepted without migration.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Are new enum values breaking?
What is consumer-driven contract testing?
How would you roll out a breaking change?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

OpenAPI Contract

Opening drill

Concept questionMedium~7 minIntegration & Data / 7 of 7

Interview question

How would you test that an API change remains compatible with its consumers?

Test API contracts and compatibility

Combines schema diffing, real provider tests, consumer expectations, generated clients, semantic scenarios, and rollout evidence to prevent accidental API breaks.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

OpenAPI checks, schema compatibility, consumer contracts, additive changes, versioning, and deployment order.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A schema catches structural changes, but compatibility also includes runtime serialization, headers, errors, defaults, ordering, and behavior that a client depends on. The test strategy needs both machine-readable contracts and representative use.
I publish the API contract from the actual build and compare it with the supported baseline. CI flags removed operations or fields, new required input, type and nullability changes, enum changes, and altered responses. Provider integration tests then call the real HTTP pipeline and verify important status codes, headers, content types, and response examples. Additive optional fields are normally allowed; intentional breaks require an explicit migration or version decision.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Schema comparison is necessary but not sufficient. Consumer-driven contracts capture assumptions such as a stable problem type, pagination cursor, default sort, or header that the provider schema may not express. I keep those contracts focused on behavior consumers truly need rather than mirroring every response byte. Representative generated clients are compiled and exercised against the new provider. Tests use tolerant readers for additive fields and include old request examples so narrowing accepted input is detected. Contract artifacts are versioned and tied to the deployable build, not regenerated later from a different environment.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I connect compatibility tests to rollout order and ownership. Providers remain able to serve old consumers while consumers tolerate additive responses; event and database contracts get the same overlap analysis when a release spans several components. A proposed break produces a reviewed diff that names affected consumers, migration sequence, support window, and rollback behavior. CI blocks unexplained baseline churn but provides an explicit approval path so teams do not normalize blindly updating snapshots. Synthetic checks and canary traffic verify routing, serialization, auth, errors, and headers after deployment, while version usage telemetry shows whether retirement criteria are actually met. I test semantic cases the schema cannot prove: enum fallbacks, omitted versus null, stable sorting, retry behavior, error identity, and changed defaults. Contracts are deleted when consumers retire so the suite remains useful rather than becoming an archive of unknown expectations. The goal is confidence that clients keep working, not maximum snapshot volume.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Updating the baseline automatically whenever CI reports a diff.
Testing mocked controller methods instead of the serialized HTTP boundary.
Copying the entire provider response into every consumer contract.
Checking structure while ignoring defaults, ordering, headers, and error meaning.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

No one knows which fields consumers rely on.
Contract files drift from real serialization.
Breaking diffs are routinely accepted without migration.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Are new enum values breaking?
What is consumer-driven contract testing?
How would you roll out a breaking change?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

OpenAPI Contract

How would you test that an API change remains compatible with its consumers?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

How would you test that an API change remains compatible with its consumers?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper