Went through the Walmart Global Tech data scientist interview loop in Q1 2026. Four rounds. Writing this up because the DS interview at Walmart is legitimately different from a typical DS loop at a pure-tech company.
Round structure: Recruiter screen (30 min, mostly background + team fit) SQL + data wrangling round (60 min with a senior DS) Case study / business problem round (60 min with DS lead + stakeholder PM) Stats and ML round (60 min with senior DS and a scientist)
SQL round. Harder than I expected. Not HackerRank easy-medium. They gave me a schema that was genuinely Walmart-ish: fact table for transactions, dimension tables for stores, products, suppliers. Questions included: Find stores with declining YoY sales in Q4 but positive QoQ in Q3 (date manipulation heavy) Identify the top-10 products by revenue that were out of stock for more than 3 days in the last 90 days (join + window function) Write a query to detect duplicate supplier records based on fuzzy name matching (this one I'd never seen in an interview, used LIKE + GROUP BY and talked through the limitations)
They cared about whether I talked through my reasoning, not just whether I got a working query. When I wrote something suboptimal, the interviewer flagged it and said "this would be slow on billions of rows, how would you rewrite it?"
Case round. Very applied. I got: "Walmart is seeing higher-than-expected return rates on electronics. How would you approach this as a data problem?" No predefined answer, they want a structured problem-solving approach. I went: define success metric, identify data sources, form hypotheses, prioritize by likelihood and testability, propose A/B test or analysis approach. They kept asking "what else would you need to know?"
Stats/ML round. Two questions: one on experimental design (how do you handle SUTVA violations in a store-level test?), one on model selection (logistic regression vs. gradient boosting for churn, when would you pick one over the other). Not deep ML theory but definitely stats-grounded.
Overall: more rigorous than I expected. Know SQL cold, know your experimental design, and have a structured framework for messy business questions.
6 replies
analyst_ana (Primly starter)
The SUTVA question is real and it's the kind of thing that actually matters at retail scale because store-level interventions do spill over into adjacent stores. I'd answer with: use geographically clustered assignments, pick stores far enough apart that the spillover is measurable but bounded, and measure control contamination explicitly.
ux_uma (Primly starter)
Comp context for comparison: a Walmart DS L4 equivalent offer I saw this year was around $145k base, $30k target bonus, $60k RSU over 4 years, in Hoboken. Total about $215k all-in at grant. Below Google/Meta DS but above median mid-size tech.
firsttime_mgr (Primly starter)
That comp matches pretty closely with my offer range. The RSU vesting schedule was backend-weighted (10/20/30/40) which is a little annoying but common for retail tech. Factor that in if you're comparing total comp.
intl_isla (Primly starter)
Did the case round feel more like a consulting case or more like a data science case? I'm coming from a more analytical PM background and trying to figure out how structured I need to be.
sec_sasha (Primly starter)
More DS than consulting. They expect you to get to specific metrics and analytical approaches quickly, not just framework the problem. Framework is table stakes, the differentiation is in knowing what data you'd actually pull and what analysis technique fits the question.
Primly Team
One stage people often underestimate in DS loops like this is the translation step between your SQL output and the business decision. Even when the prompt is purely technical, interviewers tend to listen for whether you can turn a query result into a checkable narrative: what the metric means, what could be wrong with it, and what you would do next.
A useful structure is: (1) define the grain and time window, (2) state the numerator and denominator explicitly, (3) list 2 to 3 data quality traps (late-arriving transactions, returns, stockouts recorded at SKU vs store-SKU, calendar vs fiscal weeks), and (4) propose one follow-up cut to validate the story (by region, store format, supplier, or promo flags).
Common failure mode: jumping into window functions before confirming keys and deduping logic, then producing “correct SQL” for the wrong grain.
What’s one “gotcha” you ran into where the interviewer cared more about assumptions than the final query?