Integrating a Third-Party Service

This one comes as a project story you must tell forward: "We're adding a background-check provider. Walk me through integrating it, from first line of code to running in production." It's a composite question — HttpClient hygiene, auth, environments, contract discipline, monitoring — and the rubric rewards structure. Tell it in phases and you'll cover every box.

Phase one: the client done right

Start with the typed HttpClient: an IBackgroundCheckClient interface, a concrete class taking HttpClient in its constructor, registered with AddHttpClient<IBackgroundCheckClient, BackgroundCheckClient>(...). Say why: IHttpClientFactory manages handler lifetimes (the classic socket-exhaustion / stale-DNS pair of failure modes from new HttpClient() per call), gives you one place for base address, default headers, timeout, and resilience policies, and the interface makes every consumer testable without hitting the sandbox. Auth goes in a DelegatingHandler — API key or OAuth client-credentials token acquisition with caching — never sprinkled through call sites, and never a secret in code or appsettings.json (Key Vault / environment config; that story deepens in module 6).

Phase two: the contract you don't control

Their API will change without asking you. Defend in layers: deserialize tolerantly (unknown JSON fields ignored — the System.Text.Json default; treat missing required fields as failures, loudly), map their DTOs to your own domain models at the boundary so their naming churn doesn't ripple through your codebase, and pin the API version if they offer one. Sandbox vs prod is config, not code: base URL and credentials per environment, wired through the Azure DevOps release pipeline. Two senior touches: make sure sandbox credentials cannot reach prod endpoints (separate key vaults per environment), and script realistic sandbox test data — the sandbox's happy-path-only data is where integration bugs hide.

Phase three: it's live — how do you know it's healthy?

An integration without monitoring is an outage you'll learn about from users. Name concrete instruments: logging each call's outcome and latency (never the payload — it contains a citizen's PII), metrics on error rate and p95 latency per operation, a health check (AddHealthChecks() with a ping endpoint, surfaced to your monitoring), and alerts on error-rate spikes. Plus the operational contract: what's the provider's status page, their SLA, and your fallback when they're down (queue and retry later — the resilience and queue lessons plug in here).

Answers that fall flat

• new HttpClient() inside a using block per request — the interviewer will ask.
• No sandbox/prod separation story, or secrets in source control.
• "We'd know it's broken because users would tell us."

Practice prompts

• Tell the full integration story in five minutes: client, auth, contract, environments, monitoring.
• Explain socket exhaustion and stale DNS, and how IHttpClientFactory addresses both.
• The provider deprecates v1 in 90 days: describe your migration plan without a big-bang cutover.