Affirm DevOps / SRE Interview Questions
30 real practice questions for the mid-level DevOps / SRE role at Affirm (Fintech), spanning behavioral, technical, system design, leadership, and problem solving. Build and maintain infrastructure, CI/CD pipelines, and ensure system reliability. 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 you owned an on-call or alerting system that teammates found confusing or unreliable. What made it hard to understand, and what did you do about it?
easy~3 minWhat interviewers look for
- Candidate can articulate specifically what made the system opaque — noisy alerts, unclear ownership, missing runbooks, ambiguous thresholds — rather than describing the problem vaguely.
- Candidate took concrete steps to make behavior observable and explainable: wrote runbooks, added dashboards, rationalized alert thresholds, documented intent. Reflects Affirm's Honest Engineering principle that hidden complexity is a defect.
- Candidate measured or validated the improvement — fewer pages, faster MTTD/MTTR, positive teammate feedback — showing they closed the loop rather than just shipping a fix.
Likely follow-ups
- How did you decide which alerts were worth keeping versus just deleting?
- Did any stakeholders outside engineering — like product or compliance — need to understand what the system was doing? How did you communicate it to them?
Company context
Affirm's 'No Fine Print' value and Honest Engineering leadership principle treat hidden complexity as a first-class defect, not just a tech-debt item. For a regulated lender, an alerting or monitoring system whose behavior can't be explained to stakeholders creates real audit and incident-response risk. Affirm expects mid-level SREs to proactively simplify systems so their behavior is auditable and explainable — not just functional.
2.Give me an example of an incident where you had to follow a transaction or data flow across services you didn't personally own to understand the full scope of impact. What made it hard, and what would you do differently now?
easy~3 minWhat interviewers look for
- Candidate describes a specific incident with a multi-service blast radius — not a single-service outage — and can explain which services were involved and how the failure propagated. This demonstrates the Vertical Ownership principle that Affirm values: understanding the full system, not just your own slice.
- Candidate names specific challenges they hit crossing service boundaries: missing traces, insufficient log correlation, unclear ownership of shared infrastructure, or undocumented async Kafka consumers. Shows they understand what good observability requires at the system level.
- Candidate's retrospective answer ('what I'd do differently') is concrete — adding a specific trace ID, instrumenting a Kafka consumer, adding a dashboard for a shared dependency — not just 'better communication'. Shows learning, not just reflection.
- Candidate mentions how they communicated scope-of-impact to stakeholders during the incident, not just after. In a payments environment, knowing which transactions were affected has immediate customer and compliance implications.
Likely follow-ups
- How did you determine which customers or transactions were actually affected versus just potentially affected? What data did you use?
- What observability gaps did you discover during this incident, and did you fix them before the next on-call rotation?
Company context
Affirm's Vertical Ownership principle expects every engineer to reason about the full loan and payment lifecycle, not just the service they happen to own. For SREs, this means incidents in a microservices environment must be traced end-to-end — a payment failure at the Affirm Card layer may have root cause in an upstream underwriting service or a downstream ledger write. Affirm's on-call culture rewards engineers who can navigate the full system graph under pressure.
3.Walk me through an incident where the root cause turned out to be in a completely different service or team's domain than where you started looking. How did you trace it, and how did you coordinate across teams?
medium~4 minWhat interviewers look for
- Candidate describes a clear, methodical debugging path — following traces, logs, or metrics across service boundaries rather than guessing or escalating prematurely. This reflects Affirm's Vertical Ownership principle that engineers must understand the full transaction lifecycle, not just their own slice.
- Candidate proactively crossed team or org boundaries rather than waiting to be handed off — reached out directly, used distributed tracing tools, or read another team's runbooks. Shows ownership beyond their own service.
- Candidate describes how they communicated findings to stakeholders during the incident — status updates, incident channels, or post-mortem writing — not just the technical debugging.
- Candidate drove a lasting fix, not just a mitigation — filed a follow-up ticket, updated dashboards, or proposed an architectural change to prevent similar cross-service confusion in the future.
Likely follow-ups
- What tooling or observability did you use to cross that service boundary — tracing, logs, metrics? What was missing that made it harder?
- How did the other team react when you showed up in their domain? Were there any ownership or blame dynamics you had to navigate?
Company context
Affirm runs a vertically integrated stack — underwriting, payments, servicing, capital markets — and its Vertical Ownership principle explicitly expects engineers to trace problems across system boundaries rather than toss issues over the wall. For an SRE, this means incidents rarely stay neatly inside one service boundary, and the ability to navigate a distributed system end-to-end is a core competency, not a bonus skill.
4.Tell me about a time you spotted a risk in a deployment or infrastructure change that wasn't in anyone's review checklist. How did you surface it, and what happened?
medium~4 min5.Describe a situation where you pushed back on a technical direction from a staff engineer or engineering manager. What was the decision, how did you make your case, and how did it end?
hard~5 min6.Tell me about a Kubernetes or infrastructure deployment pipeline that was working but that engineers outside your team couldn't easily reason about or debug. What did you change, and how did you validate that it was actually clearer?
hard~5 min
Technical Questions (6)
7.We run Kafka for event streaming across our microservices. How would you set up consumer lag monitoring, and what thresholds would you alert on for a service that processes loan repayment events?
easy~3 min8.Explain how you'd design a liveness vs. readiness probe strategy for a Go service that connects to both PostgreSQL and an upstream gRPC dependency at startup. What edge cases would you handle?
easy~3 min9.We run Airflow for ML pipeline orchestration. A critical underwriting feature-generation DAG starts failing intermittently — tasks succeed in isolation but the whole DAG fails roughly 20% of runs with no consistent error. How do you diagnose and stabilize it?
medium~4 min10.You're designing the deployment pipeline for a new microservice that processes Affirm Card transactions — it needs to write to PostgreSQL and emit events to Kafka. What does your CI/CD and rollout strategy look like, and what specifically would you build in to protect against a bad deploy corrupting ledger state?
medium~5 min11.We're seeing elevated P99 latency on our loan servicing gRPC service during end-of-month repayment peaks — the service is autoscaling but latency still climbs. CPU and memory look normal. Where do you look and what do you change?
hard~5 min12.We need to migrate a high-volume PostgreSQL table that stores loan repayment schedules — hundreds of millions of rows — to a new schema with a different partitioning strategy, while keeping the service live with zero downtime. Walk me through your full migration plan.
hard~5 min
System Design Questions (6)
13.Design a health-dashboard service that gives on-call engineers a real-time view of the Affirm Pay-Over-Time checkout flow — from consumer clicking 'Pay with Affirm' all the way through underwriting decision and loan creation. What would you instrument, aggregate, and surface?
easy~3 min14.Walk me through how you'd design a secrets management system for Affirm's microservices — specifically the distribution of database credentials and payment-network API keys across a Kubernetes cluster. What does the rotation story look like?
easy~3 min15.Design a multi-region active-passive failover strategy for Affirm's loan servicing database — this is the PostgreSQL instance that stores repayment schedules and payment state for active loans. How do you handle the failover, and what's your acceptance criteria for promoting a replica?
medium~4 min16.We're launching Affirm Card in a new market and need to rate-limit outbound calls to the card network's authorization API — we have SLA commitments that say we can't exceed 500 requests per second per merchant. Design the rate limiter. How does it hold up when we have multiple instances of the authorization service running?
medium~4 min17.Design an on-call escalation and alerting pipeline for Affirm's Adaptive Checkout service — this is the critical path that generates personalized BNPL offers in real time during a consumer's checkout. How do you ensure alert quality doesn't degrade over time into noise that engineers stop responding to?
hard~5 min18.Design Affirm's deployment pipeline for a zero-downtime schema migration on the Affirm Money Account ledger table — this stores every credit and debit against a consumer's high-yield savings balance. The table has 500 million rows, is written to on every card swipe and ACH transfer, and the migration adds a new non-nullable column. How do you pull this off without data loss or downtime?
hard~5 min
Leadership Questions (6)
19.Tell me about a time you had to explain a complex infrastructure failure to a non-technical stakeholder — maybe a product manager or a finance team. How did you frame it, and what did you leave out?
easy~3 min20.Think about a time you inherited an on-call rotation or an alerting setup from someone who'd left the team. What was the first thing you did to make it yours, and what did you change?
easy~3 min21.Tell me about a time you had to make a reliability or infrastructure decision under time pressure that you weren't fully confident in. How did you communicate your uncertainty, and what did you do to reduce the risk?
medium~4 min22.Walk me through a time you had to onboard a new engineer onto a complex part of your infrastructure. What did you build or write to help them, and how did you know it worked?
medium~4 min23.Describe a time when your team's reliability practices were creating friction for product engineers — maybe slowing down their deploys or requiring gates they found annoying. How did you handle the tension between velocity and safety?
hard~5 min24.Tell me about a time you identified a gap in your team's incident response process — not during an incident, but proactively. What did you do about it, and how did you get the team to actually change their behavior?
hard~5 min
Problem Solving Questions (6)
25.Estimate how many container restarts Affirm's Kubernetes cluster handles in a typical day across the checkout and underwriting services. Walk me through your assumptions.
easy~3 min26.Affirm's checkout completion rate drops 3% on a Tuesday morning — no deploys went out, no incidents are open. How do you figure out what happened?
easy~4 min27.Estimate the total storage Affirm's audit log system needs to retain one year of loan lifecycle events — loan origination, repayment, delinquency, and payoff — across all active loans. Walk me through your math.
medium~4 min28.We're onboarding a new third-party fraud scoring vendor whose API needs to be called inline during every Affirm Pay-Over-Time underwriting decision. Their SLA is 200ms P99. How do you evaluate whether integrating them degrades our checkout latency, and what's your rollout plan?
medium~5 min29.Estimate how much AWS spend Affirm wastes per year on over-provisioned compute for services that only peak during end-of-month repayment processing. Walk me through how you'd size this and what you'd do about it.
hard~5 min30.Design a capacity planning model for Affirm's ACH payment processing infrastructure ahead of a major merchant launch that's expected to 10x our daily ACH transaction volume over 90 days. What do you instrument, model, and pre-provision?
hard~5 min