Affirm software engineer interview: what the OA actually is (and isn't)

I spent two evenings drilling timed, auto-graded problems for an Affirm online assessment that, according to the loop data I keep, does not exist. Then a reader who'd finished his Affirm software engineer interview four weeks earlier told me how his process ran: recruiter call, live technical screen, virtual onsite, hiring manager. No OA link. No countdown timer. A human on a video call for sixty minutes.

So here's the question you probably typed into a search box at 11pm, and the honest version of the answer.

"What is the Affirm OA, and what's on it?"

As of the July 2026 update on this page, Affirm's documented loop is four rounds: a 30-minute recruiter screen, a 60-minute technical screen, a three-hour virtual onsite (coding, a payments-flavored system design, and a values round), and a 45-minute hiring manager conversation. None of those four is an online assessment.

I want to be exact about what I don't know, because this is where company pages start inventing specs. I do not have verified data on an Affirm-branded assessment platform, a time limit, a question count, or a pass threshold. If some page tells you "the Affirm OA is 70 minutes, four questions, 60% to pass," ask where that number came from. Mine would be a guess wearing a lab coat.

What I can tell you is what the reports consistently describe, which is a 60-minute technical screen built around one Medium problem, with emphasis on correctness and tests. If a recruiter sends you an assessment link instead, the highest-value assumption is that it's that same screen in async form — same difficulty band, same bias toward a working, tested solution. Prep for the screen and you've prepped for both. Prep for a speed-run of eight auto-graded problems and you've prepped for a format that may not be there.

That's the whole answer, and I'd rather give it to you in three paragraphs than pad it.

"Correctness and tests" is doing more work than it looks like

Most screens I've sat in the candidate chair for reward getting to the optimal solution. Wayfair's screen wanted the O(n) answer. Capital One's wanted you to talk while you typed. The phrasing that keeps coming back for Affirm is different, and it's the part I'd underline: correctness and tests.

Here's how that changes what a passing hour looks like. A candidate who lands the clever one-pass solution and never runs it, never writes an assertion, never names the empty-input case, is submitting an unverified claim. A candidate who writes something less elegant, then says "okay, let me run three cases through this — empty list, one transaction, two that straddle the window boundary" and finds their own off-by-one on camera is demonstrating the thing the rubric is asking about.

That's where the cut happens. Not on difficulty. Almost nobody I've heard from failed the Affirm technical screen because the problem was too hard. They failed it because they burned 40 of the 60 minutes on a brute force they intended to rewrite, then ran out of clock with a half-rewritten optimization that didn't compile and zero tests. Slow is smooth. A correct O(n²) with four passing cases and a spoken sentence about how you'd get it to O(n) reads better than a broken O(n).

The problem shape they keep coming back to

One reported question from 2026, and I'm going to sit on it for a while because it tells you more than a list of ten would:

Detect split payments that together exceed a credit limit within a time window.

That's a hash map problem wearing Affirm's actual business. You have transactions — some identifier, an amount, a timestamp. Individually each one clears. Grouped by user (or card, or merchant, depending on how you clarify it) and bounded to a rolling window, they breach a limit. The whole point is that the fraud or risk signal is invisible at the row level and obvious at the group level.

What I'd do with the first four minutes, before typing anything:

• Ask what "within a time window" means. Rolling window from each transaction, or fixed buckets? These are different problems and the fixed-bucket version misses breaches that straddle a boundary. Asking this out loud is itself a signal — a risk engineer would ask it.
• Ask if input is sorted by timestamp. If yes, you get a sliding window. If no, you're sorting first and you should say so and name the cost.
• Ask about the limit. Global, or per user? Does a refund show up as a negative amount? At a company whose product is installment lending, the answer to "can amounts be negative" is almost certainly yes, and a candidate who asks it has read the room.

Then the shape:

def breaches(txns, limit, window):
    # txns: (user_id, amount, ts), sorted by ts
    from collections import defaultdict, deque
    windows = defaultdict(deque)   # user -> deque of (ts, amount)
    running = defaultdict(int)     # user -> sum inside the window
    out = []
    for user, amt, ts in txns:
        q, = (windows[user],)
        while q and ts - q[0][0] > window:
            running[user] -= q.popleft()[1]
        q.append((ts, amt))
        running[user] += amt
        if running[user] > limit:
            out.append((user, ts, running[user]))
    return out

Hash map of deques, one pass, O(n) after sorting. Nothing exotic. What earns the round is what you do next: write the test where two transactions land exactly window apart and decide whether that's inclusive. Write the one where a refund pulls the running total back under. Write the empty case. Say the number out loud — "three cases, all passing" — because that sentence is the rubric being satisfied in real time.

The other two reported question shapes are worth knowing even though they're past the screen: senior loops get "design the ledger for installment payments with refunds and partial captures," and every loop asks some version of "describe a time you disagreed with a product decision on risk grounds." Every loop. If you're at the OA stage right now, that behavioral one is the cheapest thing on this page to start building, because it takes a week of remembering, not a week of drilling.

Where the answer is genuinely "it depends"

Level changes the screen's weight. At P3 (mid), the technical screen is most of what stands between you and the onsite. At P4 (senior), it's a gate you're expected to clear comfortably, and the real evaluation is the payments-flavored design round. If you're being considered at P4 and the screen felt easy, that's not a green light — it's the warm-up.

Format may vary by pipeline. I have no data on Affirm's new-grad or university process, and I'm not going to extrapolate from the experienced-hire loop to cover it. If that's you, ask the recruiter directly on the 30-minute call: "Is there an assessment before the technical screen, and what platform?" Recruiters answer that question. It costs you nothing and it's the only source that's actually current.

What the money means

The published base band is $150K–$220K. Two things that matter more than the headline: this is fully remote in the US, so that $190K isn't discounted for living somewhere with reasonable rent — and the equity is public-company stock, not a private valuation you're guessing at. Compared to a JPMorgan or Capital One offer at the same level, the base is competitive and the equity component is where Affirm pulls ahead or falls behind depending on the share price the day you sign.

What's negotiable: level, first and foremost, then equity. Ask the recruiter on that first 30-minute call for the written expectations for the level you're being considered at. The loop is rubric-driven and the leveling is more transparent than most — that transparency only helps you if you request the document.

The verdict

Target Affirm if you want fintech compensation without moving, if you can talk about correctness like someone who's been paged at 3am, and if the phrase "partial capture" makes you curious rather than tired. Skip it if you're optimizing for the fastest possible offer — remote-first means the applicant pool is national, and the competition is real. The single highest-leverage thing to prep is not more problems. It's practicing the sentence "let me test this," and then actually doing it, on the clock, with someone watching.

My own practice file has a function at the bottom called check that takes a list of input/expected pairs and prints which ones failed. I paste it into every problem I do before I write a line of the solution, because for a long time I told myself I'd write tests if there was time left, and there was never time left.