Affirm Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about Affirm. They build consumer lending software, and a buy-now-pay-later installment is a loan.

• A single off-by-one in a payment schedule is a regulatory and trust problem, not a cosmetic one.
• A bug can mislead someone about money they owe, charge them twice, or show the wrong payment date.
• The whole engineering culture bends toward correctness, clear data modeling, and people who think about edge cases without being told to.
• A clever one-liner nobody can audit is a liability here. Trustworthy, legible, and correct-under-failure is the whole game.

2Getting the call (the part most guides skip)#

Affirm gets a flood of applicants. The cold-application pile is brutal and most resumes there never reach a human. A referral routes you to an engineer or a recruiter instead of a keyword filter, so it is worth more than a perfect resume.

How people actually get shortlisted.

• A referral from a current engineer. Find Affirm folks on LinkedIn who worked where you worked, or share a bootcamp or university. A short, specific note beats a polite one: "I spent two years on payments infra at X, I'd love a referral for the E4 backend req, here's my resume and two bullets on why Affirm." Attach the resume so they can forward it in one click.
• A resume that screams money, scale, and ownership. Affirm is a payments company. Payments, ledgers, transactions, reconciliation, fraud, idempotency, and anything high-throughput jumps off the page to a reviewer who lives in that world.
• Keywords that survive the ATS, all of them true: Python, Kotlin, TypeScript, React, Go, PostgreSQL, Kafka, gRPC, microservices, distributed systems, payments, API, AWS. A reviewer can smell a resume that lists Kafka but never touched it, and that gap surfaces in the phone screen the moment they ask what partition key you used and why.

A resume bullet that lands. Compare these two.

• Weak: "Worked on backend services and improved performance."
• Strong: "Rebuilt the settlement reconciliation job in Python + Postgres, cutting nightly run time from 40 min to 6 min and eliminating a class of duplicate-payment bugs affecting ~2k daily transactions."

Why the strong one wins:

• Numbers, a real domain, and a clear "I owned this."
• The weak one could have been written by anyone about anything.
• The strong one tells the reviewer you've already shipped the exact kind of work Affirm does: a batch job, a correctness bug, money on the line, a measured result.
• No payments work? Do the same move on whatever you had: name the system, name the metric, name the before-and-after number.

3The loop at a glance#

How the loop scales by level.

• New grads (E3) usually get a lighter loop: more CS fundamentals, a cleaner single coding problem, and often no full scale system design.
• Senior folks (E5 and up) get the full system design plus a deeper values round, often with a hiring manager or director probing whether you can own a surface area, not just a ticket.
• The E5 tell: they stop asking "can you solve this" and start asking "how would you decide." Answers that name a tradeoff out loud score higher than answers that just produce a result.

Here is how the stages chain together.

The debrief matters more than people realize.

• Interviewers write up each round and the hiring committee reads them together, usually a few days after your last round.
• One strong-no on values can stall an otherwise clean loop, which is why the behavioral round is not a formality.
• The committee weighs consistency: four lukewarm "leaning yes" writeups often lose to three clear yeses and one no, because a clear signal is easier to defend than a muddy one.

4The coding or technical rounds#

Affirm coding is medium-hard LeetCode territory with a twist: they care more about how you build than whether you find the one clever trick.

• I've passed candidates who didn't fully optimize but modeled the problem beautifully and tested it.
• I've failed candidates who got the optimal answer in silence and couldn't explain why their loop terminated when I asked.

Patterns they reuse a lot.

• Hash maps and frequency counting. Two-sum-flavored stuff, grouping, dedup, counting distinct transactions per customer.
• Interval problems. Merge intervals, meeting rooms, overlap detection. Very on-brand: think overlapping promo windows, rate windows, or whether two installment schedules collide.
• Strings and parsing. Tokenizers, simple expression evaluation, encode and decode, parsing a fixed-width record out of a settlement file.
• Trees and graphs. BFS and DFS, topological sort, shortest path on a small grid. Topo sort shows up disguised as dependency ordering between billing steps, where step B can't run until step A settles.
• Stacks and queues. Valid parentheses variants, monotonic stack, next-greater-element.
• A "design a small class" problem that bridges into the LLD round: an LRU cache, a rate limiter, or an in-memory key-value store with per-key expiry. These are a soft handoff. Do well here and the machine-coding round feels familiar.

The follow-up extensions are the real test. Difficulty is roughly LeetCode medium, with one or two pushing into hard-ish territory.

• "Now make it handle duplicates."
• "Now the input is a stream, so you can't see it all at once." You lose the ability to sort or random-access, so a heap or a running count beats re-scanning.
• "Now it has to run concurrently, what breaks." Name the shared mutable state and say what you'd lock or make atomic.
• They are testing whether your first design has room to grow.

How to actually win the round.

1. Clarify first. Ask about input size, edge cases, empty input, duplicates, negative numbers, and what should happen on bad input. Thirty seconds of real questions signals seniority and often reveals the trap. For a payments prompt, "can amounts be negative, and do negatives mean refunds" makes an interviewer sit up.
2. Think out loud the whole time. Narrate the decision, not just the keystroke: "I'll key the hash map by customer id so lookups stay O(1), and I'll store the latest timestamp as the value so I can resolve ties."
3. State complexity before you're asked. "This is O(n log n) time because of the sort, O(n) space for the map." Then say whether you can do better: "I could get this to O(n) with a bucket, but the sort keeps it readable and n is small, so I'll keep it," is a senior sentence.
4. Write code a teammate could read. Real variable names, small helpers, early returns over nested ifs. No one-letter soup. Legible beats clever.
5. Test it yourself. Walk through one normal case and one edge case out loud, tracing the variables by hand. Finding your own bug before the interviewer points it out gets a big mental checkmark, because that is literally the job.

Practice tip.

• Grab 40 to 50 mediums across arrays, hash maps, intervals, trees, and graphs.
• Redo five of them talking out loud to a wall or a webcam, timed to 30 minutes. The talking is the skill Affirm grades, and the one you can't fake on the day.
• Record one and watch it back once. It is uncomfortable, and it fixes more than another ten solved problems will.

5System design and the machine-coding / LLD round#

This is where Affirm differs from a generic big-tech loop. The machine-coding and low-level design round is common here, and it's where a lot of otherwise-strong people slip, usually on time management.

The machine-coding / LLD round#

You get a spec for a small system and build a working, runnable version in your language of choice.

• Common prompts: a parking lot, a vending machine, a splitwise-style expense splitter, a payment-plan calculator, a coupon or discount engine, an in-memory order book.
• Payments-flavored prompts show up often because they map directly to the domain.

What they're really grading.

• Clean domain modeling. One class, one job. An InstallmentSchedule computes schedules; it does not also talk to a database and format a receipt.
• It actually runs and produces correct output. Not pseudocode, not "and then it would roughly do this." Running, with a tiny main or a test that prints real results.
• Obvious edge cases handled without being told. Zero-dollar loan, a refund larger than the balance, a coupon that would push the price below zero.
• Extensibility. They love to say "now add refunds" or "now add a second currency" at the end and watch whether your design bends or snaps. A design that snaps reads as junior no matter how clean the first version looked.

A framework I give everyone.

1. Read the whole spec, then restate it in one sentence. "So I'm building X that supports A, B, C." This catches misreads before you've burned 20 minutes coding the wrong thing.
2. List the core entities out loud. For a payment-plan calculator: Loan, Installment, Schedule, PaymentProcessor. Naming them early forces the model to the surface.
3. Sketch the interfaces before writing bodies. Decide what talks to what and who owns what state.
4. Build the happy path first, run it, then add edge cases. A running happy path at minute 30 is worth far more than a perfect model that compiles at minute 59.
5. Keep state and logic separated. No god class that is impossible to extend.
6. Leave seams for the follow-up. If they'll probably add "refunds," make a Transaction type now instead of passing raw floats around. That one decision is often the difference between a two-line add and a rewrite.

Do not over-engineer.

• I've watched people reach for abstract factories and visitor patterns on a 60-minute problem and never ship working code.
• Working and simple beats clever and broken, every single time.
• If you find yourself writing an interface with one implementation and no second caller in sight, stop.

System design (E5 and up)#

For senior loops you'll get a proper scale design, usually payments-adjacent.

Classic prompts.

• Design a payment processing or checkout service (idempotency, retries, exactly-once charging).
• Design a ledger or double-entry accounting system.
• Design a loan or installment scheduling service.
• Design a rate limiter or an idempotency key store.
• Design a notification system for payment reminders.

The framework. Requirements (functional and non-functional) first, then rough numbers (QPS, data size, read-vs-write ratio), then the API, then the data model, then the high-level diagram, then a deep-dive on the hard part.

• At a payments company the hard part is almost always correctness under failure.
• Talk idempotency keys, exactly-once semantics, the outbox pattern, reconciliation jobs, and what happens when a downstream charge times out but may have already succeeded.

For the ledger prompt specifically, the answer they want is append-only double-entry.

• Every movement is two balanced rows: a debit and a credit.
• You never update a balance in place.
• The current balance is a sum or a materialized rollup over the immutable entries.
• Say that and you've shown you know why accountants and payments people trust ledgers: you can always reconstruct and audit how a balance got where it is.

A minimal shape for a charge service worth sketching on the board.

Then narrate the failure case over that picture.

• Client retries with the same idempotency key.
• The charge service checks the store, sees the key already resolved, and returns the prior result instead of charging twice.
• Spell out the write order: you persist the key as "in progress" before you call the processor, so a crash mid-charge leaves a record the retry can reconcile against instead of a silent double charge.
• That is the kind of answer that moves an E5 loop from "fine" to "clear yes."

6Behavioral and culture fit#

Do not sleep on this round. Affirm takes values seriously and a weak behavioral can sink an otherwise strong loop. I have personally watched a candidate with two strong-yes coding scores get debated into a no-hire because the values round was flat and a little blamey.

Affirm's values (know these, they'll come up by name).

• People come first.
• No fine print. (Honesty, transparency, saying the hard thing plainly instead of burying it.)
• It's an honor to serve.
• Push the boundaries.
• Simpler is better.
• Be the owner.

Prepare five or six STAR stories.

• A conflict with a teammate.
• A hard technical call you owned.
• A time you simplified something messy.
• A failure and what you changed afterward.
• A time you pushed for the customer's interest over your own convenience or a deadline.
• Map each story to one or two values out loud, because the interviewer is scoring you against those words. End a story with "and that's really the 'be the owner' one for me," so they can drop it straight into the right box.

One full worked STAR example.

Situation: Our team's nightly batch that generated customer payment schedules started silently dropping about 3% of records when the input file format changed upstream.

Task: I was on call and owned getting schedules correct again, fast, without sending anyone a wrong payment amount.

Action: Instead of patching the parser and moving on, I added a reconciliation check that compared record counts in versus out and hard-failed the job on mismatch, then I wrote a one-page postmortem and flagged the upstream team about the format change. I pushed to make the job fail loud rather than fail quiet, because quiet wrong numbers are worse than a delayed run in lending. A late schedule is an inconvenience. A wrong schedule is a customer paying money they don't owe.

Result: We recovered 100% of the dropped schedules within the day, and the new guardrail caught two more upstream format changes over the next quarter before any customer saw a wrong number.

Why that shape works.

• The number in the result maps straight onto "No fine print" and "Be the owner."
• A concrete situation, a decision you personally made, a measured outcome, and a value it demonstrates.
• Avoid stories where "we" did everything and "I" is nowhere.
• Avoid any story whose moral is that someone else was at fault. If a story has to involve a teammate's mistake, make the point about how you handled it.

In lending, a late schedule is an inconvenience. A wrong schedule is a customer paying money they don't owe.

7Your prep plan#

4-week plan.

• Week 1: 25 LeetCode mediums across arrays, hash maps, strings. Talk out loud on half of them, out loud for real, not in your head.
• Week 2: Trees, graphs, intervals, stacks. Add 20 more. Start timing yourself to 30 min and note which patterns you stall on.
• Week 3: Machine coding. Build three small systems end to end (parking lot, expense splitter, payment-plan calculator). Make them run, then make yourself add one feature to each cold.
• Week 4: System design (if E5+) plus six STAR stories mapped to the values, rehearsed aloud. Do two full mock loops with someone who will interrupt you.

2-week plan.

• Days 1 to 5: 30 mediums, focus on hash maps, intervals, trees, graphs.
• Days 6 to 9: Two machine-coding builds, runnable, with an "add a feature" extension each.
• Days 10 to 12: System design framework plus two payments prompts, or more mocks if you're E3/E4 and skipping system design.
• Days 13 to 14: STAR stories mapped to Affirm values, plus one timed mock coding round out loud.

2-day crash plan.

• Day 1: 12 mediums (hash maps, intervals, trees). One machine-coding build that actually runs. Read Affirm's values and jot one story per value.
• Day 2: Review the complexity cheat-sheet. Write four STAR stories with real numbers in the result. Do one timed problem talking out loud. Re-read the payment-processing design notes above so the idempotency and failure story is fresh.

8Why people get rejected at Affirm#

1. Silent coding. If I can't hear your reasoning, I can't pass you, even with correct code, because I can't tell correct-and-understood from correct-and-lucky.
2. The machine-coding round turns into one giant function. No classes, no clear ownership of state, no room to extend. The "now add refunds" follow-up then collapses the whole thing.
3. Over-engineering a small problem and never getting it running. A perfect design that doesn't execute scores below a plain design that does.
4. Hand-wavy data models in system design. "I'll store it in a database" with no schema, no keys, and no thought about what makes a write correct under a retry.
5. Ignoring failure and idempotency in a payments design. At Affirm that's a red flag, not a nice-to-have. A charge flow with no answer for the timed-out-but-maybe-succeeded case reads as not understanding the domain.
6. A flat behavioral round. No numbers, no clear ownership, blaming teammates, or stories that don't connect to any value. This one quietly ends more loops than people expect.

9The offer, comp and negotiation#

How to read the offer. Comp is base + RSUs (4-year vest, typically) + bonus.

• As a public company the equity is real and liquid: you can look up the share price and actually sell when it vests, so there is less guesswork than with a private startup's paper grant.
• The flip side: Affirm's stock has been volatile. Ask whether the grant is a fixed dollar value divided by price at grant, or a fixed share count, because that one answer changes what the number is really worth.

Rough 2026 ranges.

• US E4/E5: base ~$170k to $240k, total roughly $230k to $400k with equity.
• Canada: base ~C$140k to C$210k, total ~C$190k to C$320k.
• India (if a req is open): roughly ₹30L to ₹70L total for mid to senior.
• UK (limited hiring): treat London base as ~£90k to £150k if a role is open.

Negotiation tips.

1. Negotiate on equity, not just base. At Affirm the RSU grant has the most give, and the recruiter expects a counter there. Base is banded tightly by level; the grant is where a few tens of thousands a year actually live.
2. Bring a competing number if you have one. A real offer from another payments or big-tech company moves the equity meaningfully. Be honest about it, because recruiters talk and a bluff that unravels costs you leverage you can't get back.
3. Anchor to level. If your loop felt like a strong E5 but they're offering E4 comp, push on the level, because that resets the whole band, not just one number. A level bump is worth more than any single-number tweak.

One last move. Always get the full breakdown in writing: base, target bonus, grant value, and vest schedule. Then sit with it for a day before you respond. A calm "thank you, I'd like a day to review the full numbers" is a completely normal thing to say and it never costs you the offer.

10FAQ#

If you want, map these rounds onto your actual calendar and build a dated week-by-week plan around the date of your Affirm loop.