Architecture scenarioHard~12 min

Interview question

How would you test code that integrates with a third-party HTTP API?

Test external dependency boundaries

Combines protocol stubs, contract checks, sandbox tests, and failure simulation without depending on live production services.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I keep the third-party call behind a narrow client and test our business logic with a fake client. Separately, I test the real HTTP client against a local stub server or controlled handler so requests, headers, serialization, status mapping, and cancellation are exercised. Those tests include success, rate limits, timeouts, malformed responses, and safe error handling.

Full answer below

Practice focus

HTTP boundaries, protocol stubs, contracts, sandboxes, retries, timeouts, malformed responses, and secret safety.

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
External integrations fail through protocol details and operational behavior that a mock returning one DTO does not exercise.
I keep the third-party call behind a narrow client and test our business logic with a fake client. Separately, I test the real HTTP client against a local stub server or controlled handler so requests, headers, serialization, status mapping, and cancellation are exercised. Those tests include success, rate limits, timeouts, malformed responses, and safe error handling.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I add contract checks from the provider specification or recorded safe examples and run a smaller sandbox suite when the provider offers one. Sandbox tests use dedicated credentials and unique data, and they are not required for every local run. I do not call the live production API from normal CI. Retry tests verify both eligibility and overall deadline, especially that non-idempotent operations are not duplicated.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
No single layer proves the integration completely. Local protocol tests give speed and failure control; contract checks detect drift; sandbox checks reveal authentication or provider-environment differences; production observability detects what cannot be reproduced. I version fixtures, redact payloads, rotate test secrets, and make provider outages distinguishable from product regressions. When a provider defect escapes, I preserve the response safely and add the smallest regression guard at the layer that can reproduce it.

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

Mocking only the deserialized DTO.
Calling production from CI.
Recording credentials or personal data in fixtures.
Retrying every failed POST.

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

Details

No test exercises request headers or serialization.
Provider outages make the whole PR pipeline fail.
Fixtures silently drift from the current contract.

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.

What belongs in a protocol stub?
How would you test retries?
When should a sandbox test run?

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.

Integration Sync

Opening drill

Architecture scenarioHard~12 min

Interview question

How would you test code that integrates with a third-party HTTP API?

Test external dependency boundaries

Combines protocol stubs, contract checks, sandbox tests, and failure simulation without depending on live production services.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

HTTP boundaries, protocol stubs, contracts, sandboxes, retries, timeouts, malformed responses, and secret safety.

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
External integrations fail through protocol details and operational behavior that a mock returning one DTO does not exercise.
I keep the third-party call behind a narrow client and test our business logic with a fake client. Separately, I test the real HTTP client against a local stub server or controlled handler so requests, headers, serialization, status mapping, and cancellation are exercised. Those tests include success, rate limits, timeouts, malformed responses, and safe error handling.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I add contract checks from the provider specification or recorded safe examples and run a smaller sandbox suite when the provider offers one. Sandbox tests use dedicated credentials and unique data, and they are not required for every local run. I do not call the live production API from normal CI. Retry tests verify both eligibility and overall deadline, especially that non-idempotent operations are not duplicated.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
No single layer proves the integration completely. Local protocol tests give speed and failure control; contract checks detect drift; sandbox checks reveal authentication or provider-environment differences; production observability detects what cannot be reproduced. I version fixtures, redact payloads, rotate test secrets, and make provider outages distinguishable from product regressions. When a provider defect escapes, I preserve the response safely and add the smallest regression guard at the layer that can reproduce it.

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

Mocking only the deserialized DTO.
Calling production from CI.
Recording credentials or personal data in fixtures.
Retrying every failed POST.

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

Details

No test exercises request headers or serialization.
Provider outages make the whole PR pipeline fail.
Fixtures silently drift from the current contract.

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.

What belongs in a protocol stub?
How would you test retries?
When should a sandbox test run?

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.

Integration Sync

How would you test code that integrates with a third-party HTTP API?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

How would you test code that integrates with a third-party HTTP API?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper