Headway Software Engineer Interview Experience — Onsite with a Rate Limiter, an Airbnb Design Question, and an AI-Assisted Debugging Round

Coding

The problem: implement a Fixed Window Rate Limiter.

Implement a rate limiter middleware for a web service built on FastAPI and Uvicorn. Every request has to satisfy both of these at the same time:

• Global limit: at most 100 requests per minute
• Domain limit: at most 3 requests per second per domain

If either limit gets triggered, the request should be rejected. They wanted the fixed-window version specifically. I wrote it pretty slowly, and by the time I finished there wasn't much time left, so I don't know if there was originally supposed to be a follow-up — something like asking about a sliding window.

System design

As a startup, design Airbnb. Mostly about how to search listings.

AI coding

Problem: debug an insurance eligibility status bug.

This is an AI-assisted debugging project. You're free to use an AI agent like Codex CLI to understand the existing full-stack codebase, reproduce the issue, find the root cause, and implement a fix.

Project tech stack:

• Backend: Python + FastAPI
• Frontend: TypeScript + React
• Dev environment: CodeSignal Web IDE
• Free use of an AI agent allowed
• Main coding time was about 45-50 minutes

Background: the system stores patients' insurance information and periodically checks each patient's current insurance eligibility. The data model roughly consists of two kinds of records.

User Insurance represents the insurance info a patient registered, which includes a cached field, eligibility_status. This field represents the eligibility status, e.g.:

• SUCCESSFUL
• NOT_ELIGIBLE
• UNKNOWN

Eligibility Lookup represents the result of each eligibility check. The same insurance record can have multiple lookups:

Patient
└── User Insurance
    ├── Eligibility Lookup: three days ago
    ├── Eligibility Lookup: yesterday
    └── Eligibility Lookup: today

Each lookup is a snapshot of the check at that point in time. The most recent lookup should represent the currently known eligibility status.

Reported issue: the patient list page shows each patient's readiness, or eligibility status. Some patients were incorrectly shown on the page as having passed the eligibility check, even though their most recent eligibility lookup didn't actually succeed.

I hadn't written Python in a long time, so I did pretty badly in this round, and it never got to the follow-up — I spent all my time just fixing the bug.