Walmart · Data Scientist
Updated · 2026-09-22

Walmart Data Scientist
Interview Questions & Guide 2026

THE 60-SECOND BRIEF

This guide covers what a Data Scientist at Walmart is expected to do and how to prepare for the interview.

Most of the loop measures decision-making under uncertainty rather than recall. You are scored on whether you state your assumptions, commit to an estimate you can defend, and say explicitly what evidence would change it.

Walmart candidates report 3 rounds · ≈ 3-5 weeks. The stages below are what candidates describe, not a published process.

Join order, return and inventory grains without fan-outSeparate true demand from stockout-censored salesSize promotions on incremental margin, not revenue

32 min read

Browse Data Scientist questions

See the practice prompts

18Practice promptsAcross five skill areas
3With worked solutionsIncluded in the practice prompts

This guide covers what a Data Scientist at Walmart is expected to do and how to prepare for the interview.

01

Recruiter Screen

reported

A screening call is a matching exercise run by someone who will not evaluate your statistics. They are checking that the work described on your resume is work you personally did, and that its scope matches the level the role is written for. Logistics get settled in the same half hour so nobody spends an interviewer's afternoon on a mismatch. The answer that fails is the one narrated in the plural. If every sentence is 'we built' and 'the team decided', there is nothing specific to write down about you. Name the piece that was yours, the decision you made inside it, and what changed after.

What to demonstrate

  • Whether the ownership implied by your resume survives one round of follow-up about who actually did which part
  • Whether your described scope (data size, stakeholders, what shipped) matches the seniority the role is written at
  • Whether timeline, location and compensation expectations make the rest of the loop worth scheduling

How to prepare

  • Rewrite your top three resume bullets in the first person singular, each with the decision you made and what moved afterwards, then say them out loud once so the 'we' does not return under pressure
  • Attach one number to each project: the baseline, the change, and the window it was measured over. Where impact was never measured, say that plainly rather than inventing a figure
  • Settle your compensation range before the call and give it as a range with a reason behind it, such as current total comp or a competing timeline, instead of deflecting the question twice
PracHub interview research ↗
02

Technical Screen

reported

Much of what gets scored here happens out loud while you type. Nobody can see your reasoning inside a half-written query, so five silent minutes read as being stuck even when they are not. State the plan in plain language first: which tables, what grain you are aggregating to, and the one filter that defines the population. Then write it. The narration doubles as insurance, because a wrong plan gets caught early and cheaply while a wrong query gets caught at the end with no time left to redo it. A timed statistics section, where one exists, is a separate test with its own clock.

What to demonstrate

  • Whether the query you write matches the plan you just described
  • What you do with a hint, meaning whether the correction gets absorbed or the first approach gets defended
  • Whether you can debug your own wrong output by reading the result set and naming which part of the query produced the anomaly

How to prepare

  • Solve three problems while screen-sharing into a recording, then watch it back and mark every stretch longer than thirty seconds where you said nothing
  • Practise compressing the plan into one sentence before typing, then check afterwards whether the finished query actually matched it
  • Time yourself on statistics questions that carry a business reading, such as what a confidence interval does and does not claim, rather than re-reading notes without a clock
PracHub interview research ↗
03

Virtual Onsite Loop

reported

Where a loop includes a partner from outside the data team, that conversation usually carries the same weight as the technical ones and gets the least preparation. The person opposite you will not follow a derivation and does not need to. They are working out whether having you involved would make their decisions better or slower. The failure mode is not being too technical. It is answering a question about a decision with a description of your method, leaving the translation to them. What they carry into the debrief is the sentence you handed them, not the analysis underneath it.

What to demonstrate

  • Whether a statistical result arrives as something the partner could act on, with the one caveat that would change their decision kept and the rest left out
  • Whether you can state what you need from their side, in their terms: instrumentation that does not exist yet, a definition they own, or a holdout they have to agree to
  • Whether uncertainty is given as a range someone can plan against, rather than as hedging that invites them to ignore the result
  • Whether you ask what decision is actually on the table before explaining anything

How to prepare

  • Take a result you know well and write the version for someone who stops reading after one sentence, then the three-minute version, and check the short one is not the long one with the qualifications stripped out
  • For a past project, list everything you asked a non-technical partner for and how you phrased it, then rewrite each ask so it names what goes unmeasured without it
  • Practise saying where a result does not apply, out loud, in one sentence that a partner could repeat accurately to someone else
PracHub interview research ↗

PracHub editorial advice for the preparation topics above.

01

Crediting promotions and channels by last click, especially coupon codes

A discount code handed to a partner or an influencer is claimed by customers who were already at checkout, so last-click attribution books organic demand as partner-driven, and the reported return on that spend is an artefact of the code's visibility at the basket rather than of any persuasion. The same mechanism makes email and paid search look strong because they sit close to a purchase that other activity created. Incremental effects need a holdout, a geo split or a switched-off period; where none is possible, at minimum report the share of code redemptions from customers whose session began before any partner touchpoint, because that number alone usually collapses the claim.

02

Comparing average order value across a change that alters basket composition

Free-shipping thresholds, multi-buy offers and minimum-spend coupons make customers bunch their basket just above a cut-off, so average order value moves because the mix of orders changed, not because anyone is spending more per item. The same trap appears when a change suppresses small orders: average order value rises while total revenue falls. Decompose into units per order and price per unit, look at the whole basket-value distribution rather than the mean (the bunching is visible as a spike at the threshold), and evaluate the change on revenue per session rather than on the conditional mean of orders that happened.

03

Answering a product-sense question with a list of features

Answer with a decision and the measurement that would settle it: the hypothesis, the primary metric, the guardrails, and the result that would make you not ship. A feature brainstorm cannot be wrong, which is exactly why it earns no points.

04

SQL that silently fans out on a one-to-many join

State the grain of each table and the grain you want in the result before writing the join. Pre-aggregate the many side to the join key, or use EXISTS or a window function, and verify with a row count against COUNT(DISTINCT id) rather than trusting that the numbers look plausible.

Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.

15 technical prompts3 include a worked solution

How do you select appropriate priors and interpret posterior distribut…

medium
statistics and probability

How do you select appropriate priors and interpret posterior distributions in Bayesian A/B testing frameworks?

Approach
  1. Translate the result into the decision it informs, in one plain sentence.
  2. Say what the estimate is of, and over what population it generalises.
  3. Write down the assumption the method needs before you use the method.
Follow-up
  • How would you explain this result to someone who does not know statistics?
  • What sample size would you need to detect an effect half this size?

If a newly launched recommendation algorithm increases click-through r…

medium
machine learning and modelling

If a newly launched recommendation algorithm increases click-through rate but decreases average order value, how do you decide whether to roll it out?

Approach
  1. Say how the offline result would be validated online before it is trusted.
  2. Frame the prediction: the label, the moment of prediction, and the action it triggers.
  3. Set a baseline first, so any model has something honest to beat.
Follow-up
  • How would you choose the decision threshold, and who owns that choice?
  • What would you monitor after launch to know the model is still valid?

Write a data-quality checker for order and return lines

mediumWorked solution
data qualityinvariantspandasgrain

Given order_lines (order_line_id, order_id, sku_id, quantity, unit_list_price_cents, unit_paid_price_cents, line_discount_cents, placed_at_utc, shipped_at_utc, delivered_at_utc, cancelled_at_utc, line_status, fx_rate_to_usd) and return_lines (return_line_id, order_line_id, quantity_returned, refund_amount_cents, initiated_at_utc, return_reason), write a checker that returns one row per check with check_name, severity, n_failing, pct_failing and up to five example ids. Cover key uniqueness, timestamp ordering, status-timestamp agreement, over-refund, and cumulative returned quantity exceeding the quantity ordered.

Approach
  1. Write each check as a function returning a boolean mask over a named frame, then run them through one driver that assembles the report. Uniform shape is what lets you add a check later without touching the reporting code.
  2. Separate row-level checks from aggregate checks. Over-refund on a single return row is row-level; cumulative quantity_returned per order_line_id exceeding the ordered quantity only exists after a groupby, and a row-wise checker will pass a line returned twice for its full quantity.
  3. Encode the status contract explicitly: delivered requires delivered_at_utc non-null and cancelled_at_utc null; cancelled_out_of_stock requires cancelled_at_utc and forbids shipped_at_utc; placed forbids all three. Ordering checks must skip nulls rather than treat a null as failing, since a line legitimately has no delivered_at_utc until it lands.
  4. Assign severity by what the failure does downstream, not by how alarming it looks. A duplicate order_line_id double-counts revenue and blocks a metric refresh; a return initiated before delivery is expected for a refused delivery and belongs at warning with return_reason reported alongside.
  5. Report pct_failing against an explicit denominator per check, because the denominator differs: uniqueness runs over all lines, the delivery ordering check only over lines with a delivered timestamp.
Worked solution 30 min
  1. Implement checks: duplicate order_line_id; placed_at_utc <= shipped_at_utc <= delivered_at_utc among non-null pairs; status-timestamp agreement per the contract above; unit_paid_price_cents > unit_list_price_cents while line_discount_cents > 0; fx_rate_to_usd <= 0 or null.
  2. Implement the aggregate check: group return_lines by order_line_id, sum quantity_returned, join to order_lines, flag sum > quantity.
  3. Implement over-refund: refund_amount_cents > quantity_returned * unit_paid_price_cents on the joined row, allowing an explicit tolerance for tax if a tax column is in scope.
  4. Assemble the report with a consistent example-id column and sort by severity then n_failing descending.
  5. Seed a fixture with one known violation of each check and assert the report finds exactly those counts.
EXPECTED RESULTA DataFrame with one row per check, in which a seeded fixture containing exactly one violation per check reports n_failing equal to 1 for each, and the multi-RMA overflow check fires on a line with two return rows of one unit each against an ordered quantity of one.
Follow-up
  • Which of these checks would you run as a hard gate before the nightly metric refresh, and which would you only alert on? Defend the boundary.
  • The cumulative returned quantity exceeds the ordered quantity on 0.2 percent of lines. Name two upstream mechanisms that produce this legitimately and two that are bugs.
  • How would you turn this into a trend rather than a snapshot, and what threshold would trigger a page?

For someone who has spent the last year in notebooks, dashboards or modelling work and has not written raw SQL under time pressure. The first four days rebuild query fluency against a fixture you control and can verify by hand; the last three attach that fluency to the rest of the loop.

Small steps. Visible outcomes.0 / 7 completed
ONE WEEK · YOUR PACE

Prepare, practise & reflect

One practical outcome each day. Spend longer where you need it.

0 / 7 done
01Build a fixture you can check answers against
  • Create a local Postgres or SQLite database with four tables (users, sessions, events, orders) holding roughly 200 rows you generated yourself, so you know the contents well enough to predict every result.
  • Deliberately seed the cases that break queries: a user with no sessions, a session with no events, two orders sharing a timestamp, a NULL in one join key, and one duplicated user row.
  • Before writing any SQL, hand-compute five answers on paper (how many users placed at least one order, median orders per ordering user, and three others) and save them as the ground truth for the week.

Deliverable: A one-command seed script plus a text file of five hand-computed answers to grade every later query against.

Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗
02Joins, filters and NULL semantics
  • Answer "which users have no orders" three ways (LEFT JOIN with IS NULL, NOT EXISTS, NOT IN) and confirm that the NOT IN version returns zero rows once the subquery contains a NULL, because the comparison is never TRUE.
  • Reproduce the LEFT JOIN that silently collapses to an inner join by putting a right-table predicate in WHERE, then fix it by moving the predicate into the ON clause, and record both row counts.
  • Create a fan-out bug on purpose by joining orders to order_items and summing the order total, then correct it with a pre-aggregated subquery and explain in one line which table changed the grain.

Deliverable: One annotated .sql file holding the three join traps, each with the wrong result and the corrected result side by side.

Practice prompt ↗Practice prompt ↗Practice prompt ↗
03Window functions and frames
  • Write three window queries against the fixture: a running order total per user, the rank of each order within its user by value, and the day gap to that user's previous order, then check each against the day-one ground truth.
  • Run ROW_NUMBER, RANK and DENSE_RANK over a column containing ties, print all three side by side, and write one sentence on when each is the correct choice.
  • Switch one query from the default frame (RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, which is what you get when ORDER BY is present and no frame is written) to ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, and explain why the output differs only when the ORDER BY column has duplicates.

Deliverable: Three verified window queries plus a short note explaining the RANGE versus ROWS difference in your own words.

Practice prompt ↗Practice prompt ↗Practice prompt ↗
04The four analytical query patterns
  • Write a monthly retention grid: first order month per user, then months-since-first as the column, and verify that month zero equals the cohort size exactly.
  • Sessionize the events table under a 30-minute inactivity rule using LAG plus a cumulative sum over a new-session flag.
  • Build a four-step funnel that counts distinct users rather than events at each step, and state the rule you applied to a user who reaches step three without ever logging step two.

Deliverable: One file with the retention, sessionization and funnel patterns, each carrying a one-line note on the assumption it bakes in.

Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗
05Write SQL the way you will have to write it live
  • Set a 12-minute timer and solve three medium prompts in a plain editor with no execution and no autocomplete, then run them and tally syntax errors separately from logic errors.
  • Narrate one solution aloud while writing it, stating the grain of each intermediate result (one row per user, one row per user-day) before you type its body.
  • Rewrite your slowest solution as a CTE chain where every CTE name states its grain, and time yourself re-solving it from blank.

Deliverable: A recording of one narrated solution plus an error tally that separates syntax from logic.

Practice prompt ↗Practice prompt ↗
06One day for everything that is not SQL
  • Write the preconditions of the two-sample t-test from memory, then check them: independent observations, and a difference in means whose sampling distribution is approximately normal, which at large sample sizes follows from the central limit theorem rather than from normality of the raw values.
  • Write the difference between an odds ratio from logistic regression and a relative risk, and state the condition under which the two are close (low outcome prevalence).
  • Prepare a 90-second answer to "how would you know this model is any good" that names the metric, the baseline you would beat, and the cost of the errors you care about.

Deliverable: One page of notes covering test preconditions, the odds-ratio caveat and the model-quality answer.

Practice prompt ↗Practice prompt ↗
07Full loop rehearsal
  • Run a 45-minute mock with someone willing to interrupt: 20 minutes of SQL, 15 minutes defining a metric, 10 minutes on a past project.
  • Re-solve from blank the two queries you were slowest on this week and compare the times against day five.
  • Write a five-line answer to "walk me through a project" that puts a number in the first sentence and names the decision the work changed.

Deliverable: Mock feedback notes plus a timed project narrative you can deliver without reading it.

Practice prompt ↗Practice prompt ↗Worked solution ↗

Expand any day for tasks and deliverables. Your progress is saved on this device.

Interviewers here are not checking whether you can describe a project. They want the decision you made, why you made it under the information you had, and what changed afterwards that someone else could measure. A story that ends at 'I built a model' has no ending. Say what the model caused, or what you stopped doing because of it.

Tell me about a time you disagreed with a senior engineering or produc…

medium
behavioural and stakeholder questions

Tell me about a time you disagreed with a senior engineering or product decision. How did you resolve the conflict?

Approach
  1. State the situation in two sentences and spend the rest on your reasoning.
  2. Close with what you would do differently, concretely.
  3. Pick a story where you drove the decision, not one where you observed it.
Follow-up
  • What would you do differently if you ran that project again?
  • How did you know the outcome was caused by your change?

Disagree with a product manager about a recommendation slot

medium
surface metricsholdout analysisdisagreement

A product manager wants to ship a recommendation module that raised slot click-through by thirty-one percent and slot-attributed revenue by nineteen percent over a two-week test. You have the holdout and can compute site-wide net revenue per session. Over the same window the treatment arm shows a higher net unit return rate and higher promotional depth on purchased lines, and site-wide revenue per session is flat within noise. The product manager has a launch date. Present your position in a fifteen-minute meeting and state what you recommend.

Approach
  1. Concede the surface result rather than disputing it. Click-through did rise. The open question is whether the units are new or moved from a search result, another slot or a later visit.
  2. State the measurement claim in one sentence: slot-attributed revenue counts capture, and only the holdout prices the counterfactual of what those customers would have bought anyway.
  3. Give the site-wide read with an interval, and say whether the test was powered to detect the effect size being claimed. Flat within noise is not evidence of no effect, and treating it as such is the fastest way to lose the argument to someone who notices.
  4. Bring the two mechanisms that explain the gap and point at where they are visible: the module surfaces more apparel and more discounted stock, which moves quantity_returned in fct_return_line and line_discount_cents in fct_order_line.
  5. Recommend something shippable this week rather than a block: launch behind a holdout that stays on, with site-wide net revenue per session after returns as the read at return maturity, and the decision rule agreed now.
Follow-up
  • The product manager says returns take ninety days and the launch cannot wait. What do you ship on in the meantime?
  • What result would make you say the module is working?

Tell a team their test cannot be read before Friday

hard
powerskewed metricsreturn maturity

A checkout test has run eleven days. Conversion is 2.4 percent in control and 2.7 percent in treatment, and the team wants to ship on Friday. Revenue per visitor is higher in treatment, driven by a small number of very large baskets, and the return window on those orders has not closed. The engineering lead has already announced the win internally. You are asked for sign-off. Give your answer, the evidence behind it, and a path that lets them ship without pretending the result is something it is not.

Approach
  1. Compute rather than assert. State the minimum detectable effect the observed sample supports at a 2.4 percent baseline, then say whether a 0.3 point absolute lift sits inside or outside it. An objection without that number reads as caution and loses to a launch date.
  2. Separate the two problems, because they have different fixes. Conversion may simply be underpowered. Revenue per visitor is a different failure: the mean is driven by the tail, so it needs a cap declared before the data was seen or a bootstrapped interval, and a cap chosen now is not a cap.
  3. Run the mechanical checks first because they are cheap and they end arguments: sample ratio mismatch, the triggered-population definition, and whether both arms drew on the same constrained inventory.
  4. Quantify the return exposure concretely: the share of treatment revenue sitting in orders whose return window is open, and what the category's matured net unit return rate would do to the lift if applied to it.
  5. Offer a path rather than a veto. If the change is reversible and the downside is bounded, ship it, with the read scheduled at return maturity and the decision rule written down now, before anyone knows which way it goes.
  6. Handle the premature announcement quietly and separately. It is a fact to correct, not a position to negotiate against, and making it the topic guarantees the measurement argument is lost.
Follow-up
  • The team says the large baskets are real revenue and capping throws away the win. What is your answer?
  • What decision rule would you write down today so this same conversation does not happen on the next test?
  • 01

    Tell me about a time you disagreed with a senior engineering or product decision. How did you resolve the conflict?

  • 02

    A product manager wants to ship a recommendation module that raised slot click-through by thirty-one percent and slot-attributed revenue by nineteen percent over a two-week test. You have the holdout and can compute site-wide net revenue per session. Over the same window the treatment arm shows a higher net unit return rate and higher promotional depth on purchased lines, and site-wide revenue per session is flat within noise. The product manager has a launch date. Present your position in a fifteen-minute meeting and state what you recommend.

  • 03

    A checkout test has run eleven days. Conversion is 2.4 percent in control and 2.7 percent in treatment, and the team wants to ship on Friday. Revenue per visitor is higher in treatment, driven by a small number of very large baskets, and the return window on those orders has not closed. The engineering lead has already announced the win internally. You are asked for sign-off. Give your answer, the evidence behind it, and a path that lets them ship without pretending the result is something it is not.

PracHub interview preparation framework ↗
Is this an official Walmart interview guide?

No. It is PracHub's own research and practice material for the Data Scientist role at Walmart. Rounds and questions reflect what candidates have reported, not a process Walmart has published, and they change over time. Confirm the current format and scope with your recruiter.

PracHub interview research ↗
How difficult are the technical interviews compared to other major retail and technology companies?

The technical bar is exceptionally high, blending rigorous coding assessments, advanced statistical theory, and domain-specific case studies. Expect interview questions to probe deeper into underlying mathematical and architectural assumptions than typical coding-only screens.

PracHub interview research ↗
How much emphasis is placed on behavioral and leadership questions during the loop?

Behavioral evaluations are integrated throughout the loop, often paired with technical debriefs or hiring manager rounds. Interviewers assess how you handle ambiguity, collaborate across functions, and navigate project failures in high-pressure environments.

PracHub interview research ↗
What is the typical timeline from initial recruiter screening to final offer?

The timeline varies by team and location, typically spanning from three to six weeks from the initial recruiter contact through technical screens, virtual on-sites, and final deliberations. Maintaining responsive communication with your recruiter helps keep the process moving efficiently.

PracHub interview research ↗
Are remote work options available for Data Scientist roles?

Remote flexibility depends heavily on the specific organization and hub location, such as Bentonville, Sunnyvale, or San Bruno. Many teams operate on hybrid models requiring periodic collaboration in designated tech hubs, while others support remote arrangements.

PracHub interview research ↗
Sources & methodology 3 sources ↗

No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.