Trees & Graphs

A recurring detail in Salesforce coding rounds: the interviewer pastes a tree problem into a shared editor and gives you nothing to start from. No TreeNode class, no adjacency list, no parsing helper. You define the structure, you build the test input, then you solve. Candidates who have only ever filled in a function body inside prepackaged scaffolding lose three or four minutes here. They hunt for a class that was never going to appear. Build it from scratch. Practice writing the node and the graph by hand so that part is muscle memory and the clock goes to the algorithm.

Trees and graphs are a steady slice of the loop, not the loud center of mass that arrays and strings are. The bar is moderate and the set is standard: depth-first and breadth-first traversal, each one iterative and recursive, plus the two graph workhorses that keep coming back. Those two are connectivity by union-find and ordering by topological sort. What changes at Salesforce is the framing. The company runs one of the largest CRMs in the world, so the same algorithms show up as account hierarchies, contact merges, and field dependencies. An interviewer will sometimes hand you the problem that way and watch whether you spot the graph underneath.

The Salesforce angle

Build the node yourself, out loud, before you touch the algorithm. When the editor is empty, the first thing to type is the structure: a TreeNode with a value and two child pointers, or a defaultdict(list) for a graph. Say why as you go, that a binary tree is a node with left and right children, that an adjacency list maps each node to its neighbors. This is partly a real-skill check and partly a Salesforce habit, since the platform's own object model is hierarchical to the core. Accounts have parent Accounts, the role hierarchy is a tree, record types nest. Scaffolding a clean node in twenty seconds shows the interviewer you have modeled real data before, not just memorized solutions.