Why APIs Questions Reveal More Than Any Resume Line

import os
import requests

BASE = os.environ["API_BASE"]
HEADERS = {"Authorization": f"Bearer {os.environ['API_TOKEN']}"}


def fetch_all_products(page_size=20):
    page, ids, total = 1, [], None
    while True:
        r = requests.get(f"{BASE}/products",
                         params={"page": page, "page_size": page_size},
                         headers=HEADERS, timeout=10)
        assert r.status_code == 200
        data = r.json()
        total = data["total"]
        items = data["items"]
        assert len(items) <= page_size
        ids.extend(item["id"] for item in items)
        if len(items) < page_size:
            return ids, total
        page += 1


def test_pages_cover_all_items_without_duplicates():
    ids, total = fetch_all_products()
    assert len(ids) == len(set(ids)), "duplicate items across pages"
    assert len(ids) == total, "total does not match items returned"

"For list endpoints I checked four things.

First, page size: no page returns more than requested.

Second, I walked every page and collected the IDs. If
the list had more IDs than the set, items were repeated,
which usually means the sort order was not stable.

Third, the count of collected IDs had to equal the total
the API reported.

Fourth, I requested a page beyond the end and checked it
followed the contract - an empty list in our case.

We ran this on a test environment with fixed data,
because new items added during the run can shift pages."

import time
import requests


def get_with_backoff(url, headers=None, params=None, max_retries=3):
    """Retry only on 429, honouring Retry-After when present."""
    for attempt in range(max_retries + 1):
        r = requests.get(url, headers=headers, params=params, timeout=10)
        if r.status_code != 429:
            return r
        if attempt == max_retries:
            return r
        retry_after = r.headers.get("Retry-After")
        wait = int(retry_after) if retry_after and retry_after.isdigit() \
            else 2 ** attempt
        time.sleep(wait)
    return r

def test_rate_limit_returns_429_with_retry_after():
    """Run this on its own, never in the parallel functional suite."""
    statuses = []
    last = None
    for _ in range(200):
        last = requests.get(f"{BASE}/products",
                            headers=LIMIT_TEST_HEADERS, timeout=10)
        statuses.append(last.status_code)
        if last.status_code == 429:
            break

    assert 429 in statuses, "limit never reached in 200 calls"
    assert "Retry-After" in last.headers

# LIMIT_TEST_HEADERS uses a dedicated test key, so hitting
# the limit does not block other tests or other teams.
# The 200-call cap is our assumption about the configured
# limit; read the real value from the API docs.

# pip install requests responses pytest
import os
import requests
import responses

# Full charge endpoint of the provider, from the test env
PAY_URL = os.environ["PAY_URL"]


def charge(amount):
    r = requests.post(PAY_URL, json={"amount": amount}, timeout=5)
    if r.status_code == 503:
        return {"status": "RETRY_LATER"}
    r.raise_for_status()
    return r.json()


@responses.activate
def test_charge_handles_provider_outage():
    responses.add(responses.POST, PAY_URL, status=503)
    assert charge(499) == {"status": "RETRY_LATER"}


@responses.activate
def test_charge_success():
    responses.add(responses.POST, PAY_URL, status=200,
                  json={"status": "PAID", "id": "ch_1"})
    assert charge(499)["status"] == "PAID"

"We split tests into layers. Most tests mock the
payment call, so they check our own handling: success,
decline, timeout and a 503 from the provider. Those run
on every commit and never depend on the sandbox.

A small set of integration tests calls the real sandbox.
They run nightly and before releases. If the sandbox is
down, those are marked as blocked, not failed, and we
note it in the report.

The risk with mocks is drift, so when the provider
changes its API we update the mocked responses from
their documentation."

For each API line on your resume, fill in:

CLAIM: "Automated REST API tests using Python"

Situation I can describe:  pagination on /products
Tool and code I used:      pytest + requests
One problem I hit:         duplicates on page 2
How I fixed or reported it: logged sort-order bug
What I would add now:      schema checks

If you cannot fill in 'One problem I hit', the claim
is probably bigger than your experience. Either build
that experience in a practice project, or reword the
line to match what you did.

Prepare a 60-second answer for each situation:

1. Testing a paginated list endpoint
2. Suite fails with many 429 responses
3. A dependency (payment, SMS) is down
4. API returns 200 but data is wrong
5. A field changed type after a release
6. Tests pass locally, fail in CI
7. Test data from one test breaks another
8. Response is slow only for some requests

For each: what you check first, the tool or code,
and how you report the result.

Give your partner your resume and this list.
They pick ANY line and ask one situation question.

Score each answer 1-3:
  1 = definition only
  2 = steps but no real detail
  3 = steps, a real problem and a trade-off

Any line scoring 1 twice:
  -> rewrite the resume line, or
  -> build a small project that covers it

Repeat until every line scores 3 at least once.