Block · Primly Community

Block data scientist interview (SQL + case + stats), full loop breakdown

ds_dmitri · 4 replies

Interviewed at Block for a mid-senior DS role on the Cash App Trust and Safety team in February 2026. Did not get the offer (they went with someone with more fraud/risk modeling experience specifically) but the process was thorough enough that I can give you a real picture.

Interview structure for DS at Block: Recruiter screen (30 min, standard) DS phone screen (60 min, SQL + one stats question) Onsite: 4 rounds total SQL deep dive Product and metrics round Statistics and ML round Behavioral / leadership round

SQL round. Harder than most. The problems aren't 'write a GROUP BY.' Mine involved window functions, a self-join on a transactions table, and a question about detecting anomalous behavior over a rolling window. If you're not comfortable with LAG/LEAD and PARTITION BY, prep that. They use BigQuery internally, or at least the interviewer mentioned BQ syntax at one point.

Product and metrics round. This was the most interesting one. They gave me a scenario: 'Cash App introduced a new feature to help users track recurring expenses. How would you measure if it's working?' I had to define success metrics, identify potential confounders, and design an A/B test. They pushed on experiment design specifically: what's your randomization unit, how do you handle network effects in a peer-to-peer payments context, what's the minimum detectable effect size you'd accept.

Statistics and ML. Covered probability (basic conditional prob, Bayes), model evaluation metrics, and one question about class imbalance in a fraud detection context. They wanted SMOTE / resampling discussion and alternatives.

Overall the DS loop felt closer to a rigorous ML eng loop than some 'can you make a chart in Tableau' DS loop. Bring your stats and your experiment design game.

4 replies

analyst_ana

The network effects in A/B testing question for a peer-to-peer product is actually a hard problem. Standard SUTVA assumptions break down when users interact. Did they expect you to give the 'right' answer or just show you knew the problem existed?

ds_dmitri

More the latter. I said the right answer is cluster-based randomization (randomize by social graph cluster rather than individual user) but I was upfront that this is operationally complex and the simpler fallback is to use a holdout of entirely distinct users with minimal connections to the treatment group. They seemed satisfied that I understood the tradeoff rather than having a perfect solution.

ml_mike

Class imbalance in fraud detection is table stakes for that role. SMOTE is fine to mention but also talk about precision-recall tradeoffs and calibration. Fraud models where you optimize for AUC but care about actual false positive rate at your operating threshold is something real practitioners know and interviewers at companies like Block care about.

de_derek

BQ syntax vs. standard SQL is mostly fine but watch out for DATE_DIFF and TIMESTAMP functions. BigQuery is annoying about date types in ways that will bite you if you only know Postgres syntax.