Mastercard · Primly Community

Mastercard data scientist interview (SQL + case + stats): full breakdown

ds_dmitri · 5 replies

Finished the Mastercard DS loop in March 2026 for a mid-senior data scientist role on the fraud analytics team. This is the most detailed breakdown I could find anywhere, so here's what I actually saw.

Round breakdown (final loop was 4 interviews):

SQL round (60 min): Heavy. Two questions, both multi-table joins with aggregations. One involved a transactions table, a merchants table, and a cardholders table. Asked me to calculate 30-day rolling fraud rates per merchant category. The second was a rank/window function problem: find merchants in each category whose transaction volume dropped more than 20% month-over-month. These are not toy problems. You need to be comfortable with CTEs, window functions (ROWNUMBER, RANK, LAG), and writing clean multi-step queries.

Statistics / ML round (60 min): Mix of probability, stats fundamentals, and one modeling question. Specific things I got: Probability: bag of balls problem (classic), expected value calculation for a payment routing decision Stats: difference between Type I and Type II error in the context of a fraud detection model. They asked what matters more in fraud and why (false negatives are missed fraud; false positives are declined legitimate transactions). This context is important. ML: walked through a fraud model end-to-end. Feature engineering discussion was substantial. They asked about class imbalance specifically.

Case / business problem round (45 min): Given a scenario: authorization rates for small merchants have dropped 3% over the past quarter. Walk me through how you'd diagnose this. I structured it like a product analytics problem: first understand the data, then segment (by region, card type, merchant category, time of day), then hypothesize causes, then describe what analysis I'd run to test each. They pushed on my segmentation choices.

Behavioral (45 min): Standard STAR format. They asked about a time I had a surprising finding in analysis that changed a business decision. They also asked how I communicate technical results to non-technical stakeholders. Pretty standard but they probe for specifics.

Overall bar: Solid. Not FAANG-tier in ML depth but definitely not easy. The SQL and business case are the differentiators. If you can't write clean SQL under pressure and think through a metric degradation problem, you'll struggle. If you can do those well, the stats/ML round is manageable.

FYI the role I was interviewing for was in Purchase, NY (HQ). Remote was explicitly not an option.

5 replies

analyst_ana

The rolling 30-day fraud rate query sounds genuinely hard to write cleanly on the spot. Did they expect a perfect solution or is walking through the approach enough?

ds_dmitri

Approach first, always. I stumbled on the window function syntax (couldn't remember if ROWS vs RANGE mattered for rolling windows in their dialect) and they were fine with me talking through it. They corrected me and said "right, in our environment it's X." Running solution matters less than showing you know what you're trying to express.

ml_mike

The class imbalance question in fraud is a classic that people still fumble. What did you say? SMOTE? Threshold tuning? Just curious how deep they wanted to go.

ds_dmitri

I mentioned a few options: undersampling majority, oversampling with SMOTE, adjusting class weights in the loss function, and tuning the classification threshold post-training to optimize for precision-recall tradeoff instead of accuracy. They responded most to the threshold tuning discussion and asked follow-ups about F-beta score and choosing the right beta for a fraud use case.

market_realist

Good to know the SQL round is genuinely hard. I've been seeing companies claim their SQL rounds are hard and then giving me basic GROUP BY questions. This sounds like the real thing.