PhonePe Senior PM Interview — Thin-File Merchant Lending

It tests whether you can design a working-capital lending product for small PhonePe merchants who have no formal credit history. The interviewer probes how you segment the merchant base, which PhonePe transaction signals you would underwrite on, how you prioritise under constraint, how you define a north star and guardrail metrics, and whether you respect the NBFC lender-of-record and RBI digital-lending structure. It is product sense applied to a real PhonePe surface, not framework recitation.

Lead with the user, not the loan. Name a specific thin-file merchant segment and why the bureau cannot serve them, then design underwriting from what PhonePe already sees, daily QR collections, settlement volume, tenure on the network. Make one explicit prioritisation call and say what you are cutting. Define a north star metric with its denominator plus a guardrail that detects the book going bad. Tie the design to the NBFC partner and the regulator. Defend your choices when pushed.

Jumping to a loan product before defining which merchant segment and what problem. Reciting a generic product framework with no PhonePe or India grounding. Proposing an eligibility metric with no denominator or guardrail. Designing as if PhonePe lends off its own balance sheet, ignoring the NBFC lender of record. Folding on a reasonable position the moment the interviewer pushes back. Staying at platform abstraction and never naming a concrete merchant, signal, or repayment mechanic.

It behaves like the relentless PhonePe loop the candidate reports describe. It probes every claim, asks for the denominator behind a metric, and interrupts when an answer drifts into generic theory. It never praises mid-interview and never lists the answer for you. The difference is consistency and a transcript-backed scorecard at the end: it will not let a vague answer pass, and it names the exact tradeoff or guardrail you could not justify.

Every answer is evaluated from the transcript against role-specific dimensions: merchant segmentation, signal-based underwriting design, prioritisation under constraint, metric and guardrail rigour, and partner plus regulatory reasoning. There is no points reveal during the conversation. Afterwards you get a scorecard that quotes the moment your structure held and the moment it broke, with the specific tradeoff or risk control you could not defend.

Do not start designing the loan. Spend the opening defining who you are building for: pick a concrete thin-file merchant segment, a small kirana or soundbox merchant in a Tier 2 town with steady PhonePe collections but nothing on CIBIL, and state why traditional bureau underwriting rejects them. Confirm the scope is a working-capital product, not a long-tenure consumer loan. Then signal your plan: segment, underwrite on PhonePe signals, prioritise, instrument with guardrails.

Hold the position if it is sound and show your reasoning with a concrete PhonePe signal, for example daily QR collection consistency and tenure on the network as a repayment-capacity proxy. Do not abandon a reasonable design the instant you are challenged, that reads as low conviction. But if the interviewer gives you a genuinely better argument, for example adverse selection in a segment, update visibly and say what you would change. Defending and updating both score; folding does not.

It names a specific merchant segment and why they are invisible to CIBIL, then underwrites from named PhonePe signals like settlement volume and QR collection consistency rather than generic alternative data. It makes one explicit prioritisation call and states the cut. It defines a north star with a denominator and a guardrail that flags the book going bad, like early delinquency by vintage. It places the NBFC as lender of record and respects RBI digital-lending limits, and it holds up under pushback.

It runs about 20 minutes as a single product-design section. It moves through a warm-up on who you are building for, a core block on signal-based underwriting design, a pressure block on prioritisation, risk guardrails, and the NBFC and regulatory constraint, and a short reflection block on what you would change in your own design. The pacing mirrors a real PhonePe loop round.

No, but you should understand the basics this round assumes: that a thin-file merchant has no credit bureau record, that PhonePe sees their payment transactions but is not itself the lender, that an NBFC partner carries the loan under RBI rules, and that a lending product needs risk guardrails, not just growth. The briefing covers the PhonePe merchant-lending context so you can reason about the design rather than recall trivia.

Risk symmetry. A pass designs a credible loan and underwriting from PhonePe signals. A strong pass also instruments the downside: it names the specific guardrail metric that would tell them the thin-file book is quietly deteriorating, reasons about adverse selection in the segment they chose, and accepts the NBFC and RBI constraint as design inputs rather than afterthoughts, all while defending the design under sustained pushback.