Walmart Backend Developer Interview Questions
Backend work at a retailer with stores, an online store, and a big supply chain is mostly about keeping orders and stock data honest while it moves between many systems. Prepare to talk through order states, stock counts that disagree, messages that arrive late or twice, and the database and caching choices behind each answer. What to show here: data you can trust between stores, warehouses, and shoppers. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How Walmart hires, in its own words, and its questions for every job →
1. Tell me about a time two systems held different numbers for the same thing, like stock or order status, and you had to decide which one to trust.
- Describe the two systems and the mismatch.
- Explain how you traced where each number came from.
- Share the decision on which system owns the truth and why.
- Describe the fix and how you kept them in sync afterward.
“In a past project, our order service said an item was reserved, but the stock service showed it free. I traced both values back to their events and found the stock service dropped reservation messages during a restart. I argued the stock service should own the count, and the order service should only ask, not store its own copy. We added a replay of missed messages on startup and a nightly check that flags mismatches. That gave us your result, and I learned to always ask which system owns a number before I trust it.”
Weak answers pick a system by gut feeling or simply overwrite one value without finding why they drifted.
2. Describe a time you had to change an API that other teams depended on. How did you avoid breaking them?
- Explain why the API had to change.
- List who depended on it and how you found out.
- Describe the versioning or additive change you chose.
- Share how you communicated, migrated callers, and removed the old path.
“Our order lookup API returned a single delivery address, but we needed to support orders split across pickup and shipping. Changing the field would break every caller. I added a new list field next to the old one and kept the old field filled with the first address. I checked request logs to find every caller, then wrote a short migration note with examples and sat with two teams to update their code. Once logs showed no one reading the old field, we removed it. Nobody had an outage, and the process became our team's template.”
Weak answers change the contract in place and rely on other teams to notice, or never remove the old path.
3. Design an inventory service that answers whether an item is available, both for a shopper browsing online and for a store preparing a pickup order, when shelf counts are often a little wrong.
- Separate on-hand count, reserved quantity, and a safety buffer per store and item.
- Pick storage: a transactional database for reservations, a fast read store for browsing.
- Describe how sales, returns, and shelf corrections update counts.
- Explain how confidence in the count changes what the shopper sees.
“I would track, per store and item, the on-hand count, the quantity already reserved for orders, and a small buffer because shelf counts drift. Available to promise is on-hand minus reserved minus buffer. Reservations need strong consistency, so they live in a relational database with row-level updates. Browsing reads can come from a faster copy that may lag slightly. Register sales, returns, and worker recounts all send updates. When an item is close to zero, I would show a softer label like limited stock rather than promising it, so fewer pickup orders fail at the shelf.”
Weak answers treat one number as the full truth and ignore reserved stock or the fact that store counts are imperfect.
4. Model the life of an order that is split, with some items picked up at a store and others shipped from a warehouse. What states and transitions would you define?
- Split the order into fulfillment groups, each with its own state.
- Define allowed transitions and reject invalid ones.
- Derive the overall order status from the group states.
- Cover partial cancel, partial refund, and a group that fails.
“I would treat the order as a parent with fulfillment groups: one for store pickup, one for warehouse shipping. Each group has its own states, like placed, picking, ready, picked up or shipped, delivered, and cancelled. Transitions are stored in a table, and the code rejects anything not allowed, like going from delivered back to picking. The parent status is calculated from the groups, so the shopper might see partly ready. If one item cannot be found, only that line is cancelled and refunded, and every transition is written to a history table for support.”
Weak answers use one status for the whole order, which cannot describe half picked up and half in transit.
5. Stock updates flow as events from stores and warehouses to a central service, and they can arrive late, twice, or out of order. How do you keep counts correct?
- Give each event a unique id and a per-location sequence or timestamp.
- Store processed ids to skip duplicates.
- Decide between change events and absolute counts, and how each handles gaps.
- Add periodic full snapshots to repair drift.
“Each event would carry a unique id plus a sequence number per store and item. The consumer records processed ids, so a repeated event is ignored. If an event arrives with an older sequence than one already applied, I skip it for absolute counts, or hold it briefly if it is a change like minus one. Mixing both is risky, so I prefer stores to send changes for speed and a full count on a schedule. The full count overwrites drift from any lost messages. I would also alert when a store's sequence has a long gap.”
Weak answers assume events arrive once and in order, or only mention retries without saying how duplicates are ignored.
6. Product pages show whether an item is in stock at the shopper's store. How would you cache that answer, and when would you refuse to use the cache?
- Cache per store and item with a short expiry for browsing.
- Clear or update cache entries when stock events arrive.
- Skip the cache and read the source at reservation or checkout.
- Protect the source when many cache entries expire together.
“For browsing, a slightly old answer is acceptable, so I would cache availability per store and item with a short expiry, and also update the entry when a stock event comes in. At checkout it is different: reserving an item must read the real inventory service, because a stale yes becomes a failed pickup. To avoid a flood of reads when many entries expire at once, I would add a little random time to each expiry and let one request refresh an entry while others wait. I would also track how often checkout disagrees with the cache.”
Weak answers use the same cache for browsing and checkout, or pick a long expiry without thinking about what a wrong answer costs.
7. Why do you want to work on order and inventory systems for a retailer that runs stores, an online store, and its own supply chain?
- Say what makes this data problem interesting to you.
- Tie it to stores, warehouses, and online orders working together.
- Link to your own backend experience.
- Say what you want to learn.
“Most backend work I have done ends at a database row. Here, a row stands for a real item on a real shelf, and it moves between stores, warehouses, and a shopper's door. Keeping that data correct while it changes in many places at once is the kind of problem I enjoy. I have built order APIs before, but never with physical stock that can be miscounted or damaged. I want to learn how to design for that messiness, and I like that a good fix shows up as a shopper who gets exactly what they ordered.”
Weak answers talk only about scale or brand, and never mention stores, stock, or orders.
8. A store worker marks a pickup order ready, but the shopper's app still says preparing, and the shopper received the ready message twice. How do you investigate?
- Pull the order's state history and the related events by order id.
- Check whether the ready event was published, consumed, and applied.
- Find why the notification fired twice, such as a retry without a dedupe key.
- Fix both, repair affected orders, and add alerts.
“I would start with the order id and look at its state history and the events around it. If the ready event was published but the order still says preparing, the state update likely failed after the notification step ran. The consumer then retried the whole handler, so the message went out again. I would reorder the handler to save the state first, and give each notification a key based on order id and state, so a retry cannot send it twice. Then I would find other orders stuck the same way, fix them, and add an alert.”
Weak answers blame the mobile app without checking server events, or fix the duplicate message but not the stuck status.
No figures on this page: pay depends on the level, the city and the offer in front of you. When the offer comes, the free salary negotiation script helps with that part.
The questions above are the prep. On the real call, ClapAssist helps with the ones you did not practice.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your live interview audio and screen are never stored. Your resume and notes are saved to your account so the app fills them in on any computer. It is hidden from screen share on every plan, including Free; only you can see it.