A practice prompt we wrote. No company or candidate report names it, so it carries no company tag.

How to answer

Handle each behavior once, in its layer, with a test. Say the layers first: “A transport that makes one request with a timeout, a retry policy around it, and a pager on top that never sees a retry.”

  1. Read the contract. How does it page (cursor or page numbers), signal the limit (429, quota headers) and fail (500s, timeouts, a truncated body)? If records change while you page, page numbers skip or repeat them.
  2. Classify responses in one place. 429 waits for Retry-After when sent, as seconds or a date (RFC 9110, section 10.2.3); the header is optional (RFC 6585, section 4), so without it, back off as for a 5xx. Honor it up to the job’s budget and fail clearly beyond. 5xx, timeouts and a 200 whose body doesn’t parse back off with , capped. Other 4xx fail at once, with the body in the error; 408 is the exception, since the client may repeat it (RFC 9110, section 15.5.9).
  3. Retry the page, not the run. The pager holds the cursor, so a late failure retries that page only. Stop on an empty cursor, raise if a cursor repeats, and dedupe by ID.
  4. Stay under the limit. If the limit is documented, a client-side keeps you under it.
  5. Test with a scripted fake and a fake clock. One test per behavior: 429 then success, sleeping what the header said; 500 forever, raising after the cap and naming the page; a 400, sent once; a duplicate ID across pages.

Get one page through the transport first, then add each behavior with its test. The trap is one try/except around the whole loop that restarts from page one: every transient error repeats the work before it, and on a long run the job may never finish. The flaky API integration drill gives you the mock server.

GlossaryExponential backoff with jitterRetrying with growing, randomized delays so that clients recovering from the same failure do not retry in lockstep.More on Exponential backoff with jitterGlossaryToken bucketA rate-limiting algorithm that refills tokens at a fixed rate and allows bursts up to a capacity.More on Token bucket

Follow-ups

What the interviewer may ask next, once your first answer is on the table.

  • The API uses page numbers, not cursors, and records are added while you page. What goes wrong, and how do you detect it?
  • The job dies halfway through. How does the next run pick up without fetching everything again or missing records?
  • The customer says the vendor’s stated limit is lower than what the API enforces. Which one does your client respect?

Where answers go wrong

  • Wraps the whole pager in one try and except that restarts from the first page, so every transient error repeats all the work before it.
  • Tests against the real clock and real sleeps, or only tests the happy path, so the retry and rate-limit code has never run.

Answer this in two minutes

Write the answer you would say out loud. The clock starts with your first word.

Two minutes

Model answer

“Before code, the contract, as I’d confirm it with whoever owns the API. GET /items?limit=&cursor= returns data and next_cursor, and a missing cursor means the last page.

Learn this in Module 5: Practical coding for FDE rounds, part of the curriculum.