Snowflake Coding Interview Questions

Snowflake's coding interview questions are LeetCode-style, tilted toward what a data warehouse runs on. Two families lead: topological sort and DAG scheduling (two Premium questions I through III) and data-structure design (a Premium question, LRU Cache, a Premium question, Snapshot Array). An online assessment on HackerRank or CodeSignal gates the pipeline with dynamic-programming and correctness rigor, and two Snowflake-only axes, a team-gated C++ systems round and role-dependent SQL, sit on top. Correctness at data scale is graded ahead of cleverness.

Topological sort is the one pattern that shows up more at Snowflake than almost anywhere else, so if you drill a single thing before the loop, drill that. The prerequisite-ordering problems and their task-scheduling cousins recur across the graph reports more than any other family. The rest of the coding surface is what you would expect from a database company. Think of building an in-memory file system, designing a key-value store that can answer what a row looked like an hour ago, or aggregating a log without scanning it twice. Familiar algorithms, a data accent on top.

Learn the grading order early. Correctness first, then efficiency at data scale, and a clear preference for the candidate who scoped the problem before writing code. Most of the problems read like a standard medium. The twist is that the medium has a scale trap folded into it. The people across the table built a system that moves petabytes, so "it works on the sample" is not where the round ends.

The Snowflake angle

Spend the first two minutes pinning down the problem, not solving it. Snowflake interviewers reward the candidate who asks about input size, the shape of the data, and the edge cases before typing anything, and some candidates sink the round by jumping straight to code. That data accent is why: a prompt that looks like a plain medium often hides a scale trap. Aggregate this log so it holds up at a billion rows; dedup a stream that will not fit in memory. The brute force that clears the sample quietly blows the time limit on the hidden tests. Name the constraint, then justify your time and space against it; that habit pays off more here than one more clever trick.

The Rounds

An online assessment gates many SWE pipelines, then one or two live screens, then the virtual onsite. The OA is classic algorithmic work and takes any language; the live rounds run on CoderPad and your code runs live, not on a whiteboard. Exact counts flex by team and level, but the anchors below hold.

• Online assessment: HackerRank or CodeSignal. Commonly three algorithmic problems in 90 to 120 minutes, staged easy to hard, any language allowed. Scored on correctness and efficiency with every hidden test expected to pass. DP, strings, graphs, and math show up heavily, and modulo-arithmetic and overflow traps are a recurring theme.
• Phone screen: CoderPad, code is run. One or two live rounds of ~60 minutes over Zoom. One reported shape is a short language-internals discussion followed by live coding; on the Java track that probes the memory model and GC, on the C++ track memory management and concurrency. Length and content vary by team.
• Virtual onsite: 4 to 5 rounds. Drawn from the five named areas: a coding round, an expertise deep-dive, an infrastructure system-design round, behavioral, and a dedicated collaboration interview. At least one algorithmic coding round is constant; a second applied or systems round is common.
• Graded on: Correctness, then scale. Requirements first, then a correct solution, then a justified argument about time and space at data-platform volume. The data accent is the throughline; a clean medium with the scale story told beats a clever one that ignores it.

The Signature Surface

The loop pulls from the usual pattern families, then tilts the mix toward what a data warehouse runs on. Two stand out. Topological sort and DAG scheduling lead by a wide margin, a Premium problems and their dependency-ordering cousins. Data-structure design sits right behind it and runs heavier than at almost any peer, because building an in-memory file system or a versioned key-value store maps straight onto Snowflake's own catalog and storage. Dynamic programming carries the OA with a correctness twist; sliding window and two-pointers, stacks and expression evaluation, heaps and intervals, and trees fill out the supporting cast. The chart counts how often each family comes up, with variants of one problem counted once.

Read the chart as where your first hours go. A Premium question family alone, two Premium questions I, II, and III, is the single loudest thing candidates report from these rounds. Behind it, the design cluster runs unusually deep: a Premium question, LRU Cache, a Premium question, Snapshot Array, a Trie or two. Those last two are essentially Time Travel in miniature, a structure that answers what a value was at an earlier point, which is exactly the question Snowflake's product answers about your data.

Topological sort anchors the section, so look at it concretely. Strip the scheduling story off a Premium question and one idea remains: repeatedly take whatever has no unmet dependency, append it, then relax its neighbors. Kahn's algorithm is the whole move. The dedicated lesson works the family end to end, cycle detection, the longest-path DP variant that makes a Premium question a Hard, and the grid multi-source BFS cousins.

The Snowflake angle

Snowflake and Databricks get filed together; they interview nothing alike. Databricks is Spark, the lakehouse, Delta, and the Photon engine, so its coding leans on distributed data processing and its design round on streaming pipelines and ML. Snowflake is a cloud warehouse: storage split from compute, immutable columnar micro-partitions, a metadata brain, and a C++ query engine. That difference is visible in the questions. You get topological sort and build-a-data-structure rounds, a SQL axis Databricks does not test the same way, and a systems round in C++ for the core engine. If you are prepping both, keep the two surfaces apart; the overlap is thinner than the shared reputation suggests.

The Two Snowflake-Only Axes

Two parts of the coding surface have no equivalent at a generic product company, and both depend on which team you land with. Neither is universal, so the first thing to settle with your recruiter is the team and the language track.

The core query engine is written in C++, so the teams that build it (execution, storage, the optimizer) run one round in the language. They grade it on whether you genuinely understand memory and concurrency. RAII and move semantics, a concurrent LRU cache, an external-merge sort that spills to disk: database primitives more than algorithm puzzles, with correctness under concurrency weighted heavily. This is team-gated; the OA and the generic coding rounds accept any language, and most teams outside the core engine work in Java or Go. Treat the C++ round as something to confirm before you prep for it, and only walk into a core-engine loop with real C++ fluency. The dedicated lesson covers it for candidates on that track.

SQL is the other axis, and it is real here in a way it is not at most companies. It covers window functions, CTEs, dedup and running totals, pulling values out of semi-structured JSON, reasoning about why one query plan beats another. How much you see scales with the role. It is heaviest for data, analytics, and solutions engineers, lighter but present for a generalist SWE, and lightest for the core-engine C++ track, which trades it for systems depth. Nobody grinds the same SQL prep; match the depth to the team you are interviewing for. The product-flavored material, Time Travel, Streams and Tasks, VARIANT flattening, cost tuning, lives in its own lesson rather than smeared across the algorithm rounds where it does not belong.

The Difficulty, Honestly

The median Snowflake-tagged problem is a Medium. That read is softer than reality, because the problems that come up most often sit toward the top of the range, roughly the most-repeated handful lean Hard rather than Medium. Four Premium questions: the signature surface is medium-hard to hard. The OA stacks three problems from easy to hard and expects every hidden test to pass, which is where the modulo-1e9+7, integer-overflow, and leading-zero traps do their damage. So prep to Hard for the OA and the high-frequency peak, even though a random tagged problem is a Medium. Snowflake does not publish these numbers; the ordering reflects how often each problem comes up across candidate reports.

Six lessons follow. They run from the two signature families through the supporting patterns, then out to the two team-gated axes. Each opens with how Snowflake frames the family and the variants it favors, then works the recurring problems with the data accent the interviewer layers on. Where a lesson rests on a base data structure or algorithm, the full build lives in the free Foundations course, so these pages stay on what is specifically Snowflake.

Common questions