Plaid · Primly Community

Plaid machine learning engineer interview: what the loop looks like and what they're really testing

ml_mike · 4 replies

cleared the plaid MLE loop in Q1 2026. l5-equivalent, applied to the fraud/risk ML team. writing this up because plaid's ML interview isn't widely documented and it's a bit different from the usual big-tech MLE format.

first thing to know: plaid's ML problems are heavily applied/domain-specific. they care about ML for fraud detection, identity verification, transaction categorization, income estimation. if you've only done NLP or computer vision, you're not out of the running but you should spend time understanding the tabular/structured data + fintech fraud space.

the loop: recruiter screen ML phone screen (60 min): one coding problem (medium, Python), plus a 20-minute ML conceptual discussion. they asked about class imbalance handling, which is very on-brand for fraud/anomaly. virtual onsite, 5 rounds: ML system design (build a transaction categorization system end to end) ML theory (probability, stats, model calibration, feature engineering for financial data) coding (one algorithm problem, one more applied coding problem - they gave a dataset and asked me to write feature extraction logic) cross-functional: how do you work with product and eng stakeholders when your model creates latency tradeoffs behavioral

what they probe in the ML system design:

for transaction categorization specifically, they asked about: feature choices (merchant name parsing, MCC codes, amount distributions, user history), model selection tradeoffs (boosted trees vs neural, latency constraints), how you handle new merchants with no history (cold start), and monitoring drift over time. this is real stuff that plaid actually ships, not contrived.

the ML theory round:

not trivia. they asked me to derive precision/recall for an imbalanced fraud scenario and explain why AUC can be misleading there. we talked about model calibration for risk scoring. they asked about SHAP for model explanations to external partners. expect depth, not breadth.

one thing that surprised me: the cross-functional round was scored seriously. they wanted examples of influencing without authority and communicating uncertainty to non-technical stakeholders. ML engineers at plaid clearly own significant product surface area.

prep focus: tabular ML (not LLMs), imbalanced classification, model monitoring, Python coding fluency, and have a real point of view on fraud/risk ML.

4 replies

marketer_mei

the calibration question is a good signal for how they think about it. a lot of companies say they do responsible ML but then can't tell you what calibration means in practice. asking about it in the context of risk scoring makes sense: a miscalibrated model means you're telling a user they have a 70% chance of fraud when it's actually 30%. that has real consequences.

de_derek

did they ask anything about the data pipelines or feature stores? or was it purely model-focused? i'm a data engineer so i work adjacent to MLE teams and always curious where the line is.

ml_mike

came up in the ML system design. i talked about feature store design and they engaged with it, had opinions about latency vs throughput tradeoffs for real-time feature serving. it wasn't a deep DE interview but you were expected to understand the infrastructure your models would run on.

content_cole

the cross-functional round for MLE roles is becoming more common at fintech companies and it makes sense. ML decisions at plaid (like changing a fraud model threshold) have downstream effects on product metrics, user experience, and even regulatory posture. they need people who can navigate that, not just people who can tune models.