PayPal interview questions
Big tech · 4 questions reported
- junior 0
- mid 0
- senior 4
These are 4 technical questions candidates reported being asked in PayPal interviews for AI engineer, ML engineer and applied AI engineer roles, each with a model answer you can say out loud in a minute or two. They cover ml system design and success criteria: 0 junior, 0 mid-level and 4 senior questions. Every question comes from a public interview write-up that names PayPal.Updated
PayPal success criteria and rubrics questions
Model answer
Use them when labels are scarce, delayed or blind to new attacks: isolation forests, autoencoder reconstruction error or graph clustering flag what's unusual, not what's known fraud.
Evaluate by proxy. Backtest on the labels you do have with precision at the top k, since investigators can review only so many. Send flagged and random cases to analysts to estimate precision and lift. Inject synthetic anomalies to check recall, and track alert volume and stability over time. Unusual isn't fraud, so feed confirmed cases into a supervised model.
PayPal mL system design questions
Model answer
LLMs aren't the core scorer. Fraud signals are mostly tabular and behavioural: amounts, velocities, device and graph features. Gradient-boosted trees or deep models trained on labels do better there, score in milliseconds at tiny cost, and give stable feature attributions for explanations.
LLMs earn a place around the model: turning unstructured text such as dispute notes, merchant descriptions and chats into features, summarising cases for investigators, drafting reason codes, and drafting rules. Keep them off the authorization path, validate their features like any other, and guard against prompt injection in user-written text.
Model answer
Score at login and payment within tens of milliseconds. Features: device fingerprint, session behaviour, recent credential or address changes, and velocities, served from a streaming feature store and logged at decision time so training sees exactly what serving saw.
Labels arrive late and noisy, from chargebacks and customer reports, so train on matured windows plus faster proxies like failed step-up challenges. Rather than only block, pick actions by risk: allow, step-up authentication or hold, with thresholds set on expected loss, and a rules fallback on timeout.
Model answer
State: the user's risk score, history, balance, recent spend and current limit. Actions: a few discrete moves, such as keep, raise or lower by a step. Transitions come from user behaviour. Reward: margin on enabled spend minus expected fraud and credit losses, which arrive late, minus a penalty for declining good spend.
Train offline from logged decisions with propensities, using a conservative method, and estimate the policy's value with off-policy estimators such as doubly robust before any live test. Then roll out to a small cohort, inside hard caps set by people.
Each question comes from a public interview write-up or video that names PayPal; the answers are ours. Not affiliated with PayPal.