Affirm Data Scientist Interview: Questions & Prep (2026)

Affirm builds buy-now-pay-later financial products that let consumers split purchases into installments. Data Scientists here typically work on credit underwriting, fraud detection, merchant analytics, and product experimentation. As of July 2026, Affirm has 191 open roles on knok's job radar, reflecting strong hiring momentum across their data and analytics teams.

The interview process typically includes a recruiter screen, a SQL or Python technical assessment, and a virtual onsite with multiple loops covering statistical reasoning, product sense, and behavioral questions. Candidates report that Affirm interviewers emphasise business impact: be ready to explain not just what model you built, but what changed because of it.

Salary ranges for Data Scientists across the India market, based on knok's job radar data:

Nationally, knok tracked 937 Data Scientist openings as of July 2026. Bangalore leads with 166 openings, followed by Delhi (46), Hyderabad (27), Pune (18), Mumbai (17), and Chennai (8).

1. Walk me through how you would build a credit risk model from scratch for a buy-now-pay-later product.
2. How do you handle class imbalance in a fraud detection dataset?
3. Design an A/B test to measure the impact of a new in-app repayment reminder.
4. How would you define and measure 'financial health' for an Affirm user?
5. Tell me about a time your model performed differently in production than expected.
6. How do you communicate model uncertainty or limitations to a non-technical business partner?
7. Write a SQL query to find users who made at least three purchases in the last 30 days but had at least one missed payment.
8. How would you detect if a merchant is gaming Affirm's checkout flow to inflate approved applications?
9. Walk me through how you decide which features to include when you have hundreds of candidates.
10. Tell me about a project where your analysis directly changed a business decision.
11. How would you build a churn prediction model for Affirm's repeat buyers?
12. How do you think about the tradeoff between model accuracy and interpretability in a consumer credit context?

Q: Tell me about a project where your analysis directly changed a business decision.

*Situation:* At my previous company, the business team was ready to expand a personal loan product to a new city, citing strong early sign-up numbers.

*Task:* I was asked to validate whether that demand signal was reliable or skewed by a promotional campaign run the month before.

*Action:* I pulled cohort data comparing users who signed up during the promotion to organic sign-ups. I compared 30-day repayment rates, average ticket size, and early closure rates across both groups, then built a logistic model predicting repayment likelihood. The promo cohort scored significantly lower. I presented the findings with a cost-adjusted view showing the risk-adjusted revenue difference between the two groups.

*Result:* The expansion was delayed by one quarter while the team tightened targeting criteria. When the city did launch, defaults in the first cohort came in below the internal benchmark, which the risk head attributed partly to better upfront screening.

---

Q: Tell me about a time your model performed differently in production than expected.

*Situation:* Six months into my previous role, a churn prediction model I had built started flagging significantly more users as high-risk than it had during the validation phase.

*Task:* I needed to quickly diagnose whether this was genuine behaviour shift, a data pipeline change, or model drift, and resolve it without disrupting the downstream operations team.

*Action:* I checked input feature distributions against the training baseline and found that a neighbouring team had changed how session duration was calculated upstream, affecting one of the top features. I retrained on a window that excluded the transition period, ran a shadow deployment to compare outputs, and switched over only after the outputs looked stable. I also set up distribution monitoring on that feature so similar changes would be caught earlier.

*Result:* The model returned to expected behaviour within two weeks. The incident led us to formalise feature monitoring as a standard step in every model deployment checklist, which caught smaller issues in the months that followed.

---

Q: How do you communicate model uncertainty to a non-technical business partner?

*Situation:* A senior product manager at my previous company wanted to set a firm approval cutoff for a new product line and was treating the model score as an exact answer.

*Task:* I needed to help her understand that the score had a range of uncertainty and that the cutoff choice involved a deliberate tradeoff, not a single correct answer.

*Action:* I built a one-page visual showing the precision-recall curve and framed it entirely in business terms: 'if we set the cutoff here, we approve more users but accept a higher share of defaults; if we tighten it, we protect margins but turn away more creditworthy users.' I removed statistical jargon and used the revenue and risk cost figures she already tracked in her own dashboards.

*Result:* She chose a more conservative cutoff than her original plan and felt confident defending it to the finance team. After launch, she came back proactively to revisit the cutoff as repayment data accumulated, showing she now understood it as an adjustable parameter rather than a fixed truth.

For credit and risk questions: Open with the business objective (reduce defaults, maximise approvals at a given risk threshold), then walk through data inputs, model selection, validation, and how you would monitor for drift in production. Always address what you would do if model performance degraded after deployment.

For product metrics questions: Use a goal-first structure. What is the product trying to achieve, what user behaviour signals success, and what guardrail metrics cannot be allowed to slip. Show you can distinguish leading indicators from lagging ones.

For SQL questions: Think out loud. State your assumptions about the schema, write the query step by step, and call out edge cases such as NULLs, duplicate rows, or timezone differences in timestamp fields. Candidates report live SQL exercises on realistic schemas at Affirm.

For behavioural questions: Use STAR. Keep Situation and Task brief. Spend most of your time on Action (exactly what you did) and Result (the measurable outcome or key learning). Candidates report that Affirm interviewers want to hear your direct contribution, not what 'the team' did.

For statistics and experimentation questions: Cover hypothesis setup, randomisation unit, sample size reasoning, test duration, primary metric, guardrail metrics, and how you would handle an inconclusive result. In a fintech context, also address the financial cost of each type of error.

Business impact, not just technical depth. Candidates report that Affirm interviewers consistently ask for the 'so what' behind every model or analysis. Connect every piece of work to a measurable outcome.

Credit and financial intuition. Even if your background is not in fintech, you are expected to reason about approval rates, default risk, and the cost of errors in a lending context. Study the basics of credit underwriting before your interview.

Clean, readable SQL. Candidates report live SQL exercises on realistic schemas. Window functions, CTEs, and self-joins appear frequently. Clarity matters as much as correctness.

Communication under pressure. Interviewers may push back on your assumptions or ask you to defend a tradeoff. They want to see how you reason when challenged, not how well you memorised a framework.

End-to-end ownership. Affirm's engineering culture, as described in their public engineering blog, values taking responsibility for outcomes after deployment. Show that you monitored model performance in production, not just at launch.

Fairness and regulatory awareness. Credit models operate under regulatory scrutiny in most markets. Showing that you think about model fairness and explainability will set you apart from candidates who treat lending as a pure accuracy problem.

Week 1: Foundations

Revise classification fundamentals: logistic regression, gradient boosting, and the metrics used in imbalanced settings such as AUC-PR, precision, and recall. Practice SQL problems focused on window functions, aggregations, and date arithmetic. Begin reading Affirm's public engineering blog to understand their actual problem space and team structure.

Week 2: Domain and Experiments

Study how buy-now-pay-later credit decisions work: approval thresholds, risk scoring, and why model explainability matters in regulated lending. Practice designing A/B experiments end to end, including sample size reasoning and metric selection. Prepare five to seven STAR stories from your own experience covering: influencing a business decision, handling a model failure, working cross-functionally, and learning from a mistake.

Week 3: Mock and Refine

Do at least two full mock interviews, one technical and one product or behavioral. Review your performance honestly and do targeted practice in any area where you hesitated. Prepare two or three questions to ask your interviewers. Good examples: 'How does the team measure the long-term impact of credit models?' or 'What does the feedback loop from production look like for your risk models?'

When you are ready to apply, knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR on your behalf, so you can focus on preparation rather than application tracking.

Jumping to models before scoping. Many candidates open with 'I would use gradient boosting' before clarifying the business problem. Always spend the first minute confirming the goal and constraints.

Ignoring guardrail metrics. When designing experiments, candidates often optimise a single metric and never mention what could break. Affirm operates in a regulated space where user financial harm is a real consideration.

Vague STAR answers. Saying 'we improved the model' is not enough. Interviewers want your specific decision, your specific action, and a specific outcome. Rehearse precision before the interview.

Not checking SQL output mentally. In live exercises, candidates write a query and assume it is correct. Talk through your expected output row by row before moving on.

Treating credit decisions as pure ML problems. A highly accurate model that cannot be explained may be unacceptable in a lending context. Show you understand the interpretability and fairness dimensions of your work.

Not asking for clarification. Candidates report that Affirm interviewers appreciate one or two scoping questions before you dive in. Silence followed by a wrong-direction answer is worse than a brief clarifying exchange.