Affirm Interview Questions
& Process for Software Engineers

Most Affirm loops open the way you would expect. A recruiter reaches out or picks up your application, and the first real gate is one or two technical phone screens: live coding, usually on a shared editor, where the brief is the one that runs through the whole process. Write something in the language of your choice, get it working against real input, then talk through time, space, and the optimization the interviewer nudges toward. Clear that and you reach the virtual onsite. Affirm lists its open engineering roles on its own careers site.

The onsite is four to five one-hour rounds, virtual and one on one, and how it is built tells you which level Affirm is weighing you for. Coding is the center of gravity: a senior loop runs two coding rounds alongside two system design rounds and a hiring manager conversation, a staff loop trades one design round for a project walkthrough, and an intern or new-grad loop is mostly technical with a single behavioral round. Afterward the interviewers file written feedback and the hiring manager settles the hire and the level with the panel. Four to eight weeks end to end is normal, and rejections can land fast, sometimes within hours of a solution that looked correct, so silence or a quick no is not something to read tea leaves into.

The mix of rounds is the clearest signal of the level Affirm is reading you at. Coding is the constant, and it is usually doubled: a senior loop runs two coding rounds and two system design rounds, a staff loop keeps two coding rounds but swaps a design round for a project walkthrough, and a new-grad loop is mostly coding with one behavioral round to close. If two system design rounds land on your calendar, Affirm is weighing you for senior, not entry.

Two habits pay across every coding round. The first is that your code is expected to run: you pick the language, get something working against real input, then discuss time, space, and the optimization the interviewer nudges toward. The second is less obvious and is where people get cut. Affirm writes its prompts deliberately vague, and one candidate with a correct, fast solution was rejected specifically for not asking enough questions first. So interrogate the prompt out loud before you type, name the data structures you are choosing and why, and treat clarification as part of the grade rather than a preamble to it.

CodingCore

The centerpiece, and usually two rounds of it at senior level. A small, recognizable problem reskinned in Affirm's merchant and lending domain, graded on whether you clarify the vague prompt before you solve it and ship code that actually runs. Medium difficulty, object-oriented and implementation heavy.

System designScale

The smaller half of the loop, one round at most levels and two at senior. Reason about data flow, APIs, and scale out loud. Documented prompts skew generic, so a payments or checkout design is the on-brand thing to prepare rather than a guaranteed question.

Hiring managerFit

A conversation with the manager who would hire you: past projects in depth, how you work with a team, and why Affirm. Conversational, not a scored values rubric.

Project walkthroughStaff

A staff-level addition. Walk one project you led end to end, the decisions and tradeoffs behind it, and the impact you owned. Present in staff loops, not in an intern or new-grad one.

Affirm's coding bar is narrow and deep rather than broad. Instead of a wide net of algorithm puzzles, it asks a small, recognizable set of problems and reskins each one in its own merchant and lending domain, so the same shape comes back wearing a different story. The difficulty sits at medium, the format is object-oriented and implementation-heavy, and candidates say repeatedly that there is not much written about the onsite, which is exactly why the recurring families are worth drilling until they are automatic.

Three families carry most of the loop. The first is weighted-random and RandomizedSet design: Insert, Delete, and GetRandom at O(1), then the twists Affirm likes, returning values with probability proportional to frequency, handling duplicates, or keying on strings. The second is a co-occurrence recommendation, framed in Affirm's own words as finding, for each merchant, the other merchant most frequently bought alongside it, which is the same problem as the generic letters-that-appear-together version. The third is a rolling-window money aggregation, store_loan and get_loan_volume summing the trailing hour, with a follow-up that asks for a constant-space answer you allow to be less accurate. Around those sit the object-oriented builds, a War card game or a decision tree you implement and run.

Be wary of any guide that promises Affirm will hand you a lending system to design. The system design rounds are real and they count, one at most levels and two at senior, but they are the smaller half of the loop, and the prompts candidates actually report skew generic. The two first-hand examples on record are Design WhatsApp and an RPC pub/sub broadcast system, neither of which touches payments or credit.

So this guide teaches a payments and checkout design with credit decisioning as its centerpiece, and it does so as the design worth practicing rather than the question Affirm is confirmed to ask. It is the on-brand problem for a company whose whole business is approving or declining a loan in the moment of checkout, and it is the most teachable version of the skills the round tests: idempotent payment writes, a ledger that stays consistent, real-time approve or decline against a risk service, and installment scheduling for buy-now-pay-later plans.

Whatever the prompt, naming more technologies does not help you. The round rewards reasoning from the access patterns and the constraints, back-of-envelope capacity math, and clean diagramming, and it wants you concrete about what gives way under load. Start from the read and write patterns, talk through your datastore choice, and reason out loud rather than reaching for a memorized architecture.

An Affirm offer is stock-heavy in a way that shapes the whole negotiation, and more so the higher you go. The package is base, restricted stock units that vest as ordinary AFRM shares, and a cash bonus that collapses toward zero at senior and staff level, where comp is really base plus RSUs. The US company median for a software engineer sits around $370K, but the number worth fixating on is the level, because that is the lever that moves most.

Affirm's IC ladder as levels.fyi reports it. The numbering starts at L4, so L4 is the entry rung and there is no L1 to L3 below it; the top rung, L8, is shown without a surfaced title. Compensation by level lives in the offer lesson.

Because AFRM is public, the stock is liquid the day it vests, typically on a four-year schedule with refreshers layered on later. The honest caveat is that AFRM is a notably volatile stock whose price swings with interest rates and consumer-credit sentiment, so the dollar value of a fixed grant moves a lot and older anecdotal totals can badly overstate today's equity. That makes grant timing and refreshers matter as much as the headline number, and it is why current levels.fyi medians, which already price the current stock, are the anchor worth trusting.

The highest-value thing you can win is the right level. The gaps between L5, L6, and L7 dwarf any bump inside a band, so if the market says you are worth more, argue the level rather than the number, and remember the ladder starts at L4, not L1. Base and a sign-on move most readily, while RSUs and the shrinking bonus barely move for individual contributors. The candidate reports hold no Affirm-specific negotiation tricks, so treat these as the standard levers applied to a company where leveling is the real prize.