Affirm Software Engineer Interview Questions
30 real practice questions for the mid-level Software Engineer role at Affirm (Fintech), spanning behavioral, technical, system design, leadership, and problem solving. Design, develop, and maintain software applications. The first 3 questions below include what Affirm interviewers actually listen for, plus likely follow-ups.
- Questions
- 30
- Categories
- Behavioral (6), Technical (6), System Design (6), Leadership (6), Problem Solving (6)
- Difficulty mix
- 10 easy · 10 medium · 10 hard
- Avg. answer time
- ~4 min
Behavioral Questions (6)
1.Tell me about a time a system you owned was doing something stakeholders couldn't explain or predict. How did you make its behavior legible to them?
easy~3 minWhat interviewers look for
- Candidate identified that the system's hidden complexity was itself the problem, not just a communication issue — aligning with Affirm's 'Honest Engineering' principle that hidden complexity is a defect.
- Candidate took concrete steps to simplify or expose system behavior — through documentation, observability tooling, improved logging, or refactoring — rather than just explaining it verbally.
- Candidate measured the impact of the change by validating that stakeholders could actually reason about the system afterward, showing accountability for the outcome.
Likely follow-ups
- What did you change about the system itself versus what you changed about how you communicated it — and why did you draw that line where you did?
- If a new engineer joined your team today and inherited that system, would they be able to explain its behavior without your help? What would still be unclear?
Company context
Affirm's 'No Fine Print' brand promise extends directly into engineering: systems that obscure their behavior from users, operators, or regulators are treated as defects, not just tech debt. This is especially high-stakes given Affirm's role as a regulated lender — auditable, explainable behavior in underwriting, loan servicing, and payment flows is both a cultural and a legal requirement. This question probes Affirm's 'Honest Engineering' leadership principle at a foundational level, assessing whether a mid-level engineer internalizes legibility as a first-class engineering value.
2.Describe a time you refactored or redesigned something — not because it was broken, but because the way it worked was confusing people who depended on it. What drove you to do it and what did you change?
easy~3 minWhat interviewers look for
- Candidate made the case for the refactor based on the cognitive cost to others — misuse, misconfiguration, support burden, or incorrect assumptions — not just personal aesthetic preference, showing alignment with Affirm's 'Honest Engineering' principle that hidden complexity is a defect.
- Candidate scoped the change to what would actually improve legibility without introducing risk — showing disciplined judgment about the tradeoff between cleanup and stability in a system others depend on.
- Candidate validated that the refactor actually improved understanding — through feedback, reduced support questions, or observing fewer misuses — rather than assuming clarity improved by fiat.
Likely follow-ups
- How did you convince your team or manager to prioritize this work when nothing was 'broken'? What was the resistance, if any?
- What did you leave out of the refactor that you wanted to change but held back on — and why?
Company context
Affirm's 'Honest Engineering' principle treats unexplainable or misuse-prone systems as defects in themselves, not just tech debt. In Affirm's financial platform — where the same payment processing or underwriting logic is shared across many teams and products like Adaptive Checkout and the Affirm Card — a confusing interface or an ambiguously named abstraction can lead to downstream bugs that affect consumer loan terms or payment correctness. This question tests whether a mid-level engineer has internalized that clarity is a feature, and that they're willing to invest in it proactively rather than waiting for a production incident.
3.Walk me through a bug or incident where the root cause ended up being in a completely different service or system than where the symptom appeared. How did you trace it, and what did it cost you in time?
medium~4 minWhat interviewers look for
- Candidate demonstrates that they followed the signal across service boundaries rather than stopping at their own service's edge — core to Affirm's 'Vertical Ownership' principle, which requires engineers to understand the full transaction lifecycle.
- Candidate used observability tooling (distributed tracing, correlated logs, metrics) systematically rather than guessing — showing methodical cross-system debugging skills relevant to Affirm's microservices stack (Kafka, gRPC, Kubernetes).
- Candidate identified a structural gap in ownership or observability that let the issue hide across boundaries, and proposed or implemented a fix to prevent recurrence — not just patched the symptom.
Likely follow-ups
- At what point did you realize the issue wasn't in your service? What was the signal that made you look elsewhere?
- Who owned the service where the root cause actually lived, and how did you work with them to get it fixed — especially if they were skeptical it was their problem?
Company context
Affirm operates a vertically integrated financial stack — underwriting, loan origination, payment processing, and servicing all interact in a single coherent system. A bug in loan repayment scheduling can trace back to an upstream underwriting decision or a downstream bank integration failure. Affirm's 'Vertical Ownership' principle explicitly asks engineers not to stop debugging at their service boundary. This question tests whether a mid-level engineer has the curiosity and tooling fluency to trace problems through a distributed system, which is an everyday reality on Affirm's platform.
4.Tell me about a feature you designed where you caught a non-obvious risk — something that wasn't in the requirements and that your team hadn't flagged — before it shipped. What was it and how did you handle it?
medium~4 min5.Tell me about a time you disagreed with a call made by a senior engineer or your manager — not just a preference, but something you thought was genuinely wrong. How did you raise it, and how did it play out?
hard~5 min6.Walk me through a time you had to understand a part of your company's stack you'd never touched before in order to solve a problem in your own service. What made you go that deep, and what did you find?
hard~5 min
Technical Questions (6)
7.You're writing a Python function that calculates the total amount a user owes across all their active Affirm loans, including principal, interest, and any upcoming installments. How would you structure and test that function?
easy~3 min8.In our Go microservices, a downstream service occasionally returns a 500. How do you decide whether to retry, and how do you implement that safely without making things worse?
easy~3 min9.We use Kafka to stream loan lifecycle events — originated, funded, first payment made, paid off, defaulted. A downstream consumer that powers the Affirm app's loan history screen is falling behind during peak checkout volume. How do you diagnose and fix the lag without dropping events?
medium~4 min10.Adaptive Checkout needs to show a user up to three different BNPL offer options — like 3-month 0%, 6-month 15% APR, 12-month 20% APR — personalized in real time at checkout. How would you design the API contract between the underwriting backend and the merchant-embedded checkout widget?
medium~5 min11.You're designing the system that processes repayments for the Affirm Card — a user swipes, and we need to decide in real time whether to put that purchase on a pay-over-time installment plan or debit their Affirm Money Account balance. Walk me through the architecture, and tell me how you'd guarantee exactly-once processing so a user is never charged twice.
hard~5 min12.Our ML underwriting model is a black box to most of the team — a loan gets approved or denied and engineers can't explain why. How would you redesign the system so the underwriting decision is auditable and explainable, both for internal debugging and for adverse action compliance?
hard~5 min
System Design Questions (6)
13.We need to send users a payment reminder 3 days before each installment is due on their Affirm Pay-Over-Time loans. How would you design the scheduling and delivery system for that?
easy~3 min14.Walk me through how you'd design a simple merchant dashboard that lets a merchant see their Affirm transaction volume and approval rates over the past 30 days. What does the data model and read path look like?
easy~3 min15.Design the system that enforces Affirm's credit limit for the Affirm Card — when a user tries to make a purchase, we need to check whether they have enough available credit and reserve it atomically. What does that look like at scale?
medium~4 min16.Affirm needs to support split-tender checkout — a user pays part of their purchase with their Affirm Money Account balance and puts the rest on a Pay-Over-Time loan. Design the transaction flow that keeps both balances consistent if anything fails mid-way.
medium~4 min17.Affirm's underwriting service needs to call three external data providers — a credit bureau, an income verification service, and a fraud scoring API — before making a loan decision. Each call adds latency. Design the orchestration layer for these calls, and tell me how you'd handle a provider going down during peak checkout traffic.
hard~5 min18.Design a system that detects when a user's repayment behavior on their Affirm loans suggests they're in financial distress — missed payments, changed payment dates, partial payments — and triggers an intervention workflow. Walk me through the architecture and the ethical guard rails you'd build in.
hard~5 min
Leadership Questions (6)
19.Tell me about a time you had to explain a technical decision to a non-engineer — a PM, a compliance officer, a business stakeholder. How did you make sure they actually understood the trade-offs?
easy~3 min20.Describe a time you took ownership of a bug or incident that wasn't technically your fault — something that fell in a gray zone between teams. What did you do, and how did it resolve?
easy~3 min21.Tell me about a time you pushed back on a product requirement because you thought it created a risk the team hadn't fully accounted for — not a technical risk, but something related to how users would be affected. How did you frame it and what happened?
medium~4 min22.Walk me through a time when you made a technical decision under real time pressure — not enough information, deadline forcing your hand — and it turned out to be wrong. What did you do after you realized it?
medium~4 min23.You're mid-sprint and a teammate's PR introduces a subtle correctness issue in a financial calculation — nothing that would cause a test failure, but something you believe would produce wrong outputs for certain loan types. How do you handle the review, and what do you do if they push back on your assessment?
hard~5 min24.Tell me about a time you identified that your team had a shared misunderstanding about how a critical part of your system worked — not a bug, but a wrong mental model that everyone held. How did you discover it and what did you do about it?
hard~5 min
Problem Solving Questions (6)
25.Affirm shows users a clear total cost of their loan upfront — no surprises. If our approval rate dropped 8% overnight and no code shipped, where would you start looking?
easy~3 min26.Rough estimate: how many Affirm Pay-Over-Time loans do you think are active in the US right now, and what's your reasoning?
easy~3 min27.A merchant integrating Adaptive Checkout tells us their conversion rate dropped 12% after we updated our checkout widget. You're the engineer on call. Walk me through how you'd triage this.
medium~4 min28.Estimate the annual infrastructure cost impact if Affirm's underwriting service added a 200ms P99 latency regression that went undetected for a full quarter. Think broadly — not just compute.
medium~5 min29.Design a fraud scoring pipeline for Affirm Card — every swipe needs a real-time fraud signal in under 50ms. How would you build it, and what happens when the model serving layer goes down?
hard~5 min30.Affirm is considering offering a 'Pay in 2' product — split any purchase into two equal payments with zero interest, due 2 and 4 weeks out. Estimate what percentage of Affirm's existing loan portfolio by count this product could cannibalize, and whether that's a problem.
hard~5 min