An API failure answer should distinguish a failed operation from an unknown outcome. Timeouts, downstream errors and duplicate requests create different recovery choices. Start by identifying whether the operation only reads data or changes state.

This original interview exercise uses a parcel-status endpoint backed by a slow tracking service. It does not describe any real employer's system. First consider a read-only request; then change the prompt to a delivery-rescheduling action.

What does a timeout tell you?

It tells the caller that a result did not arrive within the chosen deadline. It does not identify the slow component or prove that remote work never happened. Check connection, request and overall deadlines as appropriate to the client and platform.

For a read, a bounded retry may be reasonable under the service's policy. For a state-changing action, retrying without an operation identity or supported recovery design can repeat the effect.

How would you handle a slow status lookup?

Set a deliberate deadline, propagate cancellation where supported and return an honest unavailable or timeout response according to the API contract. If a cached status is allowed, label its freshness. Do not silently present an old location as a live result.

Use limited retries only for conditions the dependency supports. Repeated immediate retries from many callers can add load during an outage. Explain attempt limits and backoff rather than saying “retry until it works.”

What changes for a reschedule request?

The action may have completed even if its response was lost. Ask how the server identifies the operation, detects duplicates and lets a client query the resulting state. A user pressing the button again is another request, not proof of a new intention.

A local disabled button can improve the interface but cannot prevent retries from another tab or client. Authoritative duplicate handling belongs at the appropriate server boundary.

What should the caller see?

  • A clear indication that live status could not be retrieved.
  • A safe retry option where permitted.
  • The age of a fallback result if one is shown.
  • A way to check an uncertain action before repeating it.
  • A correlation reference when support needs to investigate.

Choose HTTP statuses based on the actual role and failure. A gateway timeout and a server's own error are not interchangeable labels. Do not return a successful status with invented parcel data merely to keep the page populated.

Which evidence would you collect?

Fictional diagnostic record:
Request operation: read parcel status
Caller deadline: explicitly configured
Observed outcome: no dependency response before deadline
Known: caller did not receive a live status
Unknown: exact cause of the delay
Next check: correlated dependency timing and error category

Keep identifiers and private addresses out of public logs. Record enough context for authorized diagnosis without copying whole customer payloads.

How do you test recovery?

Use controlled success, delayed response, explicit failure and lost-response scenarios. Verify that an older response does not replace newer UI state. For a consequential action, test the supported deduplication contract at its real persistence boundary.

A strong interview answer explains the uncertainty and the next safe action. It does not treat every exception as a reason to repeat the same request.

References and next practice

developer.mozilla.org — http · careerservices.fas.harvard.edu — career

Browse interview topics · Practise a question in Interview Challenge · How to Prepare for an Interview