Block · Primly Community

Block machine learning engineer interview: what the loop actually covers in 2026

ml_mike · 4 replies

interviewed for an MLE role at Block (the payments/risk team, not the bitcoin side) earlier this year. took the offer, but sharing the process because there was almost nothing specific about this team online.

role context: the team builds fraud and risk models. it's applied ML with a lot of feature engineering and operational complexity, not research. if you're expecting to talk about transformers all day, wrong interview.

phone screen (technical) started with a coding problem: implement a sliding window feature computation (something like rolling 7-day transaction velocity per user). this is a hint at the actual job. then a conceptual ML question: "you have a model with 98% accuracy on historical fraud data. why might this be misleading?" they want: class imbalance, temporal leakage, distribution shift. give all three.

onsite (5 rounds) ML systems design: design a real-time fraud scoring system. the classic, but they push hard. what does the feature store look like? how do you serve at low latency (think sub-100ms on a payment authorization)? what happens when the model needs to be retrained and deployed without downtime? i spent 15 minutes on the serving layer alone. ML fundamentals: gradient boosting deep dive (XGBoost/LightGBM internals), precision/recall tradeoffs in high-stakes settings, calibration. one tricky question: "your model's AUC is high but it's miscalibrated on the high-velocity segment. what do you do?" have a real answer. coding: two problems. one was a feature transformation pipeline in python (clean, efficient). second was a graph problem for network analysis (transaction graph, find suspicious clusters). not easy. experimentation/analytics: A/B testing a new model version in production. how do you handle the fact that fraud is adversarial and your control/treatment contaminate each other? this tripped me up and i gave an incomplete answer. behavioral: cross-functional collaboration, handling model failures in prod, disagreeing with stakeholders about model risk threshold.

comp (i'll share rough numbers): L5 equivalent, SF-based, base around $210k, RSUs valued at roughly $300k vesting over 4 years at the time of offer. nothing groundbreaking for SF MLE but reasonable for the complexity of the work.

4 replies

ds_dmitri

the contamination question in A/B testing for fraud is genuinely hard. the answer i'd give: isolate treatment/control at the merchant or user level (not transaction level), use synthetic control methods if full randomization breaks down, and accept that your experiment is directionally informative not precise. did they accept something like that?

ml_mike

roughly yeah. they also wanted me to talk about holdout sets kept entirely out of the experiment for calibration. i missed that and it was the weak point of my loop. still got the offer, so it wasn't a killer.

backend_bekah

"sub-100ms on a payment authorization" is doing a lot of work in that sentence. curious how deep they went on serving infra or if they just wanted the conceptual answer.

ml_mike

they wanted both. i described a two-tier approach: precomputed features in a low-latency feature store (redis/bigtable-style) for the fast path, with async refresh from the batch pipeline. they pushed on cache invalidation for rapidly changing signals.