Affirm PM Analytical Interview: Metrics, SQL, and Case Questions

TL;DR

Affirm’s product manager analytical interview tests three non-negotiable skills: metric design under ambiguity, hands-on SQL for real product diagnostics, and case framing that surfaces business trade-offs. The problem isn’t your technical accuracy — it’s whether your reasoning exposes first-principles thinking. Candidates who pass don’t just answer questions; they signal judgment early and consistently.

Who This Is For

This is for PM candidates at mid-level or senior levels (L4–L6) preparing for Affirm’s analytical round, typically the third of five interviews. You’ve passed the recruiter screen and the behavioral loop. You’re likely transitioning from fintech, e-commerce, or SaaS, and you’ve solved SQL problems before but haven’t faced Affirm’s blend of risk-informed product thinking and real-world metric ambiguity.

What types of analytical questions does Affirm ask PMs?

Affirm evaluates analytical rigor through three buckets: metric definition, SQL execution, and product cases with embedded analytics. In a Q3 debrief last year, the hiring committee rejected a candidate who correctly wrote a SQL query but failed to question the table schema — a fatal blind spot. The issue wasn’t syntax; it was curiosity.

Metric questions often start with: “How would you measure the success of Affirm’s ‘Pay in 4’ option in a new retail vertical?” These aren’t about listing KPIs. They’re tests of causal logic. The candidate who says “conversion rate” without defining the funnel step fails. The one who asks, “Are we optimizing for user acquisition, merchant adoption, or capital efficiency?” signals product sense.

SQL problems are applied, not academic. You’ll get a schema sketch — say, orders, loans, repayments — and asked to write a query diagnosing a drop in approval rates. One candidate traced a 12% decline to a single merchant’s sudden spike in high-risk applications, isolating the segment in four lines. The HC noted: “She didn’t just pull data — she surfaced a capital risk vector.”

Case questions blend analytics and strategy. Example: “Affirm’s average loan size dropped 15% last quarter. Diagnose and recommend.” Strong candidates stratify the data by user cohort, product type, and risk tier before proposing fixes. They don’t jump to “improve underwriting”; they ask whether the drop correlates with new user acquisition or merchant mix.

Not execution, but exposure: Affirm doesn’t want flawless code. They want you to expose your assumptions. Not completeness, but clarity: a partial query with clear intent beats a full one with hidden leaps. Not optimization, but trade-off articulation: every recommendation must weigh risk, capital cost, and user experience.

How does Affirm evaluate metric design in PM interviews?

Metric design is the core filter. Affirm’s business runs on risk-adjusted unit economics, so PMs must design metrics that reflect both user behavior and financial exposure. In a hiring committee debate, a candidate proposed “approval rate” as a success metric for a new BNPL product. The lead PM shot back: “Approval rate goes up if we lend to everyone — including deadbeats. What does that do to loss rate?” The candidate hadn’t linked the metric to capital impact. Red flag.

Strong metric answers follow a three-layer framework:

Behavioral intent (what user action are we driving?)
Business constraint (how does this affect risk, revenue, or cost?)
Diagnostic signal (can we isolate cause when the metric moves?)

When asked to measure checkout friction for Affirm’s embedded financing widget, one candidate rejected “conversion rate” as too broad. Instead, they proposed:

Primary: % of users who see the Affirm option and select it within 3 seconds (behavioral intent)
Guardrail: change in average risk score of users who convert vs. drop off (business constraint)
Diagnostic: segment by first-time vs. returning users to isolate onboarding friction

The hiring manager noted: “He didn’t just pick a metric — he built a feedback loop.” That’s the bar.

Not perfection, but probing: the best candidates spend 60 seconds asking clarifying questions before proposing anything. Not standard KPIs, but custom composites: “repayments per active user” beats “retention rate” because it ties behavior to financial health. Not vanity, but leveragability: if the metric moves, can the product team act on it?

How hard is the SQL portion for PMs at Affirm?

The SQL bar is moderate in syntax, high in context. You won’t write recursive CTEs. You will write queries that diagnose real product issues — and explain their business impact. The coding window is 20–25 minutes. You’re expected to deliver a working query, not just talk through logic.

In a recent interview, the prompt was: “Write a query to find the 30-day repayment rate for loans originated last week, segmented by FICO band.” Schema included loans (loan_id, user_id, amount, fico_score, origination_date) and payments (payment_id, loan_id, amount, payment_date).

A BAD candidate wrote:

SELECT AVG(paid) FROM loans WHERE DATEDIFF(CURRENT_DATE, origination_date) = 7;

No join, no segmentation, no definition of “repaid.” The interviewer moved on at minute 18.

A GOOD candidate wrote:

WITH repayments AS (
  SELECT loan_id, SUM(amount) AS total_paid
  FROM payments 
  WHERE payment_date <= DATE_ADD(origination_date, INTERVAL 30 DAY)
  GROUP BY loan_id
),
loan_fico_bands AS (
  SELECT 
    loan_id,
    CASE 
      WHEN fico_score < 600 THEN 'subprime'
      WHEN fico_score BETWEEN 600 AND 700 THEN 'near_prime'
      ELSE 'prime' 
    END AS fico_band,
    amount AS loan_amount,
    origination_date
  FROM loans 
  WHERE origination_date BETWEEN '2024-04-01' AND '2024-04-07'
)
SELECT 
  l.fico_band,
  AVG(CASE WHEN r.total_paid >= l.loan_amount THEN 1.0 ELSE 0.0 END) AS repayment_rate
FROM loan_fico_bands l
LEFT JOIN repayments r ON l.loan_id = r.loan_id
GROUP BY l.fico_band;

Then added: “This assumes partial payments don’t count as repaid. If Affirm’s policy is 90%+ paid, we’d adjust the numerator.”

The interviewer nodded. The HC later said: “She tested her own assumptions. That’s PM thinking.”

Not fluency, but fidelity: syntax errors are forgiven if logic is sound. Not elegance, but robustness: handling nulls, edge cases, and business rules matters more than window functions. Not speed, but scoping: launching into code before clarifying “repaid” or “30-day” is a fail.

How are product cases with analytics different at Affirm?

Affirm’s case interviews are not strategy theater. They’re diagnostic sprints. You’re given a business anomaly — “Weekly active users dropped 20%” — and expected to use data to isolate the cause and propose actions. The case is less about final answer, more about hypothesis structure.

In a Q2 2023 debrief, two candidates responded to: “Affirm’s merchant API error rate spiked from 0.3% to 2.1% last Thursday.”

The BAD candidate said: “We should improve server capacity and add retries.” No data, no segmentation, no timeline check.

The GOOD candidate asked:

Was the spike global or per merchant?
Did it correlate with a deployment?
Were errors concentrated in specific endpoints (e.g., check_eligibility vs. create_loan)?
Then proposed a query to count errors by merchant tier and endpoint over hourly buckets. Only after seeing the data — which showed 90% of errors came from a single enterprise merchant’s bulk eligibility checks — did they suggest rate limiting.

The hiring manager wrote: “He treated the case like a production incident. That’s how we work.”

Affirm cases demand a feedback loop: hypothesis → data check → refinement → action. Not breadth, but depth: listing 10 possible causes earns no credit. Isolating one with data does. Not vision, but immediacy: they don’t want “build AI detection”; they want “turn off the merchant’s batch job until they paginate.”

Not framework, but flow: no one wants to hear “I’d use the 4Ps.” Not confidence, but calibration: saying “I’d check the deployment log before blaming traffic” shows operational awareness. Not solutioning, but triage: the best candidates distinguish between root cause and containment.

Preparation Checklist

Practice writing SQL queries under time pressure (20-minute limit) using real product scenarios — not LeetCode-style problems.
Internalize Affirm’s business model: revenue = interest + merchant fees; cost = cost of capital + credit loss. Every metric must tie to this.
Build a mental template for metric questions: behavioral intent, business constraint, diagnostic signal.
Run through common Affirm scenarios: approval rate drops, repayment delinquency, merchant API health, user conversion in checkout.
Work through a structured preparation system (the PM Interview Playbook covers Affirm’s risk-aware metric frameworks with real debrief examples from HC discussions at fintechs like Klarna and Block).
Do mock interviews with PMs who’ve passed Affirm’s loop — especially those who sat on hiring committees.
Study public Affirm metrics: Q4 2023 earnings call mentioned 86% 30-day repayment rate and 5.1% net loss rate — know these cold.

Mistakes to Avoid

BAD: Jumping into a SQL query without clarifying the business definition of the metric.
Example: Writing a “repayment rate” query without asking whether partial payments count.
GOOD: Pausing to define success: “When you say ‘repaid,’ do you mean 100% of principal, or 90%+?” — then coding to that spec.

BAD: Proposing a single root cause in a case without data segmentation.
Example: “The drop in engagement is due to a bad app update.”
GOOD: “Let’s segment the drop by user cohort, geography, and feature usage. If it’s only in iOS 17, we isolate to the app.”

BAD: Designing vanity metrics that don’t link to financials.
Example: “I’d track daily active users for the merchant dashboard.”
GOOD: “I’d track % of merchants who use the API daily and have >5 loans — that’s engagement tied to revenue.”

FAQ

What’s the biggest mistake candidates make in Affirm’s analytical interview?
They treat it as a test of knowledge, not judgment. The candidate who writes perfect SQL but doesn’t question the schema fails. The one who proposes “increase conversion” without defining which segment or cost fails. Affirm hires for decision-making under uncertainty — not technical recall.

Do PMs at Affirm need to write production-level SQL?
No. You won’t deploy code. But you must write queries that drive product decisions. Interviewers expect correct joins, filtering, grouping, and CASE logic. Errors are acceptable if you catch them. What matters is whether the query answers the right business question.

How soon after the analytical interview does Affirm decide?
Results come 2–4 business days post-interview. The hiring committee meets weekly. If you pass, you’ll get the next interview (often the executive round) within 3 days. Delays beyond 5 days usually mean no.

About the Author

Johnny Mai is a Product Leader at a Fortune 500 tech company with experience shipping AI and robotics products. He has conducted 200+ PM interviews and helped hundreds of candidates land offers at top tech companies.

Want to systematically prepare for PM interviews?

Read the full playbook on Amazon →

Need the companion prep toolkit? The PM Interview Prep System includes frameworks, mock interview trackers, and a 30-day preparation plan.