Trees, BSTs & Linked Lists

Four different-looking asks share one row in a Walmart coding round, and it helps to meet them as a family. A tree problem hands you a recursive object and asks you to solve the two subtrees, then fold the current node into their answers. A binary search tree adds one rule on top of that shape, an ordering that has to hold everywhere below every node. A linked list asks you to move pointers along a chain and rewire the links without losing your place. None of it is exotic. The band sits at reliable medium, the editor runs your code, and the bar is a correct first pass with a clean follow-up rather than a flash of insight.

The through-line is simple: think clearly about a structure made of nodes and pointers, and build it yourself from the raw input the interviewer hands you. That input is almost always a level-order array for a tree or a sequence of values for a list. Turning it into real nodes is your first job, and no library does it for you. Drill the traversal until your fingers know it, and your head stays free for whatever the problem wraps around it.

The Walmart angle

A tree is how Walmart organizes what it sells, so the recursion you write here mirrors structures the company runs at scale. A product catalog is a tree: departments hold aisles, aisles hold shelves, shelves hold items, and a walk down that taxonomy is the same recursion you use to validate or traverse a binary tree. A price-sorted index that answers a lookup in the height of the tree is a binary search tree in its purest form. When an interviewer hands you a tree and asks whether an ordering holds, they are watching for the habit of trusting the recursion. Each node asks its children and combines the answers, instead of you trying to hold the whole tree in your head. That structural instinct is what the loop is listening for, because the systems behind walmart.com are built out of exactly these node-and-pointer shapes.