Affirm SWE Interview: Onsite Codebase Exercise Guide

Estimated read time: 8-10 minutes

Summary: The Affirm SWE onsite coding or codebase exercise can feel closer to real engineering work than a standalone algorithm task. Public evidence includes onsite loops, panel or hybrid formats, practical coding, and candidate reports about reading, modifying, and testing existing code. This guide explains how to prepare for a codebase-style round where correctness, tests, maintainability, and domain assumptions all matter.

TL;DR + FAQ (read this first)

At-a-glance takeaways

• Final loops are reported as multi-hour in some public sources, but exact structure varies by role.
• Expect coding or codebase work with engineers, senior engineers, or panel-style interviewers.
• Existing-code exercises can require reading, modifying, and testing unfamiliar code.
• Strong performance means small safe changes, clear tests, and explicit tradeoffs.
• Senior candidates should connect implementation decisions to architecture and domain risk.

Quick FAQ

Is this different from the phone screen?
It can be deeper and more codebase-like, especially in onsite or final-loop settings.

Will I receive a full production codebase?
The research does not prove that. Prepare for a realistic small codebase or existing-code exercise.

Should I write tests?
Yes. Testing is a repeated candidate-report signal.

What domain matters most?
Backend, platform, fintech, risk, credit, payments, and transaction systems are the safer general SWE focus areas.

---

1) How codebase exercises work

A codebase exercise asks you to orient in existing code and make a correct, testable change. The public evidence for Affirm includes practical coding, real-world challenges, and reports of reading, modifying, and testing code. That makes this less about reciting an algorithm and more about working like an engineer.

The interviewer may care about how you read the code, where you make the change, how you avoid side effects, what tests you add, and how you explain tradeoffs. If the task involves payments or transactions, idempotency and correctness under repeated actions can become important.

Takeaway: optimize for a safe, understandable change rather than a dramatic rewrite.

---

2) Tasks you may face

These examples turn the supported codebase and practical-coding themes into candidate-facing tasks.

• Read this existing code, explain what it does, then implement a requested behavior change.
• Add tests that prove your change works and does not break the previous behavior.
• Fix a bug in transaction handling where repeated requests can create duplicate effects.
• Modify a status-transition function so invalid transitions are rejected clearly.
• Add validation to an API-like function without changing the public contract unexpectedly.
• Improve a small piece of code for readability while preserving behavior.
• Given a real-world coding challenge, implement the core case first, then handle edge cases.
• Explain what you would refactor if you had more time and why you are not doing it now.

---

3) Level and team-specific expectations

Relevant levels: intern through staff where the role uses onsite coding or codebase exercises.

Early-career candidates should show methodical reading, basic tests, and clean implementation. Mid-level candidates should show maintainability and judgment about where to change code. Senior and staff candidates should also explain architectural boundaries, migration risk, and how the change would behave in a larger system.

For fintech-adjacent roles, treat data integrity, repeated requests, auditability, and user-impacting correctness as first-class concerns.

---

4) What strong performance shows

Strong candidates narrate how they understand the code, make targeted changes, add meaningful tests, and explain tradeoffs. They do not rewrite large sections unless the task truly requires it.

Weak candidates edit before understanding, skip tests, over-refactor, or ignore domain risk. In a transaction-heavy system, a small correctness bug can matter more than a clever abstraction.

Do this now: take a small function in any codebase, change one behavior, and add tests for old behavior, new behavior, and one edge case.

---

5) Common failure modes

Editing before reading. First understand the current behavior.

Skipping tests. Testing is central to existing-code work.

Over-refactoring. A focused change is usually safer under interview time pressure.

Ignoring domain invariants. Transactions, statuses, and repeated requests need careful handling.

Not explaining tradeoffs. The interviewer needs to see your judgment, not only the final diff.

---

6) How to prepare

• Practice reading unfamiliar code and summarizing behavior aloud.
• Practice making small changes with tests.
• Review common backend invariants: idempotency, validation, status transitions, retries, and error handling.
• Prepare to explain what you would refactor later and why.
• For senior roles, connect code changes to service boundaries and system reliability.

The codebase exercise is an engineering judgment round hiding inside a coding round.

---