Data-Structure Design

Build-a-data-structure problems lean on Snowflake candidates harder than at almost any other company, and the reason is not coincidence. Snowflake is a database, so the people across the table spend their days building exactly these things. They build a catalog that resolves a path to an object and a store that can answer what a table looked like an hour ago. They also build caches that have to be both fast and correct. When they hand you a "design a structure" prompt, they are watching you build a miniature of their own product. The miniature they reach for most, a Premium question, lands in roughly nine of ten coding reports.

The catalog of problems is small; learn it by name. It covers a Premium question, a snapshot array, an LRU cache, and design an in-memory file system. Add a hit counter, insert/delete/getRandom in constant time, a min stack, design a HashMap, and a trie for add-and-search. Each one is a clean class with two or three methods and one rule that must always hold. The coding is rarely the hard part. The grade is whether you name the right internal representation, hold the invariant on every write, and reason about the cost of each operation at the scale a warehouse runs at.

The Snowflake angle

State the API and the invariant before you touch the keyboard. Snowflake interviewers reward requirements-gathering. Say the contract out loud: "set records a value at a timestamp, get returns the most recent value at or before a query time, and timestamps for a key only ever increase." That last clause is the invariant; pin it and the structure picks itself, a sorted list plus binary search. Skip it and you reach for a scan, or a hash that loses ordering, and spend the round digging out. Two minutes of contract talk is part of what they score.