HackTheRounds Interview Experiences

Snowflake Software Engineer Interview Experience (2026) - OA Trio, Workflow Scheduling & Distributed KV Store, Offer

Snowflake 2026 SWE loop: HackerRank OA with Longest Consecutive Sequence, Group Anagrams, Rotate Image, plus 5 round onsite covering workflow scheduling, rate l

By Anonymous · 2026-03-20

Background

A recruiter from Snowflake reached out on LinkedIn in mid-February after I had spent about a year as a data platform engineer at a mid-size SaaS company. I'd been eyeing Snowflake because the warehouse-plus-compute model is genuinely novel and the infra challenges are deeper than most B2B shops. Applied through the recruiter the same day, got the HackerRank OA link the next morning.

Timeline

Online Assessment (90 min, HackerRank)

Three coding problems. No personality section, no logic puzzles, just code. The language list includes Python, Java, Go, and C++. I used Python. The time budget is tight if you hit a wall, but comfortable if you recognize the patterns.

Problem 1: Longest Consecutive Sequence

Problem: Given an unsorted array of integers, return the length of the longest consecutive elements sequence. Target runtime: O(n).

Classic hash-set walk. Put everything in a set, then for each value only start counting if x - 1 is not in the set (so you begin at run starts), and increment while x + k keeps appearing. That is amortized O(n) because each value is visited at most twice. I wrote it in six lines and moved on. The only edge case is the empty array, which returns 0.

Problem 2: Group Anagrams

Problem: Given an array of strings, group all anagrams into the same bucket. Order of groups and order within a group do not matter.

I used a defaultdict(list) keyed by a 26-length frequency tuple. Sorting the string works too, but the count vector is O(L) per key instead of O(L log L), and Snowflake's OA description specifically called out complexity, so the count vector felt safer. The gotcha is remembering to convert the count array to a tuple (lists aren't hashable).

Problem 3: Rotate Image

Problem: Given an n x n matrix, rotate it 90 degrees clockwise in place. No extra O(n^2) buffer.

Standard two-step: transpose then reverse each row. I walked through a 3x3 example on the scratchpad before coding, because the off-by-one on the transpose loop is a common trap (you loop i from 0 to n, but j from i+1 to n, not i to n). Finished all three with about 20 minutes left and used them to stress-test on edge sizes.

Recruiter Call Before Onsite

A quick 20-minute chat confirming the loop structure and that I wanted San Mateo rather than Bellevue. The recruiter told me the OA pass rate for this cycle was around 30 percent. She also flagged that Snowflake interviewers take "no extra space" literally, and if I solved something with recursion in a coding round I should be ready to justify the stack frames as constant or prove the depth.

Virtual Onsite (5 rounds, one day)

Five 60-minute rounds on Zoom with a 30-minute lunch break. Two coding, one system design, one domain deep dive on databases, one hiring manager plus behavioral.

Round 1: Coding — Workflow Scheduling

Problem: Given a DAG of tasks where each task has a duration and dependencies, schedule tasks on N workers so total completion time is minimized. Tasks can only start once all dependencies finish. A worker can only run one task at a time.

I started with the straightforward topological scan, but the interviewer wanted me to handle the worker constraint explicitly. My final solution used a priority queue keyed by (finish time, task id) for in-flight work, and a second PQ for ready tasks keyed by duration (longest first, on the theory that scheduling long-pole tasks early shortens the critical path). Complexity O((V + E) log V). The interviewer pushed back on the greedy: "Is longest-first optimal?" I admitted it is not (the scheduling problem is NP-hard in the general case) but argued it is a strong heuristic within a factor of 2 of optimal for identical workers. He seemed to accept that.

[[problem/362?company=23|Workflow System with Topological Order]]

Round 2: Coding — Rate Limiter With Per-User Rules

Problem: Implement a rate limiter that supports multiple overlapping rules per user. Each rule is (window seconds, max requests) . A request is allowed only if it does not violate any rule for that user.

This is basically a production problem rather than a Leetcode one. I maintained a deque of timestamps per user per rule, and on each allow(user, ts) I popped expired entries and checked length against the cap. O(k) per check where k is the number of rules. The interviewer asked about memory: "What if we have 10 million users and most are inactive?" I proposed lazy cleanup on access plus a background sweeper, plus moving cold users to a slower tier (or just evicting them entirely since rate limit state is best-effort). He nodded at the eviction answer.

[[problem/360?company=23|Rate Limiter with Multiple Rules]]

Round 3: System Design — Distributed Key-Value Store

Problem: Design a distributed KV store similar to the metadata service underpinning Snowflake's FDN tables. Billions of keys, single-region strong consistency, multi-region eventual, snapshot isolation for reads.

I drew the classic sharded cluster: keys hashed across N shards, each shard a Raft group of 3 replicas, leader serves writes. For snapshot isolation I proposed MVCC with a global timestamp oracle (Percolator-style), which the interviewer clearly wanted to hear because he jumped to "OK how does the TSO scale?" We spent ten minutes on timestamp batching, clock-skew tolerance, and what happens when the TSO fails. The rest was routine: consistent hashing, background compaction, range scans through iterator merging.

[[problem/365?company=23|Distributed Key-Value Store]]

Round 4: Domain Deep Dive — Databases and Concurrency

No coding. 45 minutes of rapid-fire questions: "Explain the difference between 2PL and MVCC. How does snapshot isolation avoid write skew? What is the read-your-writes guarantee under async replication? How does a B+ tree split during a concurrent insert?" I was expecting this based on the recruiter's prep doc, and I had re-read chapters 7 and 11 of Kleppmann's book the night before. The interviewer finished by asking about write amplification in LSM trees, which I hadn't prepped for, and I rambled a little before landing the answer.

Round 5: Hiring Manager + Behavioral

Half behavioral, half a walkthrough of a recent project. I picked a schema-change orchestration tool I'd built. Expect questions about conflict, disagreement, and a time you were wrong. My "wrong" story: I had pushed hard for eventual consistency on a coordination service that actually needed linearizability, and we had a subtle bug in prod for three weeks because of it. The HM nodded and wrote a lot.

Result

Offer 6 business days after the onsite. Senior SWE on the Snowpark infra team, San Mateo. Comp was lower base than I expected but the RSU grant was generous and vested on a 1-year cliff plus monthly after. The recruiter was direct about the number being "close to band max" for my level, and there was a small negotiation on sign-on only.

Tips

  1. Snowflake cares about complexity statements, not just working code. Every round someone asked me for the time and space complexity of my solution out loud. Say it before they ask.
  2. The domain round is not a freebie. It is a real filter. Read Kleppmann's DDIA chapters on replication, partitioning, and transactions. If you cannot explain what snapshot isolation is in two sentences, you will not pass.
  3. Know LSM trees and B+ trees both. Snowflake's storage layer is more LSM-flavored but the recruiters said interviewers from different teams lean different ways. Compaction, read amplification, write amplification should all be on your tongue.
  4. Rate limiting shows up everywhere. It is such a common problem at Snowflake that I saw a variant in the OA-adjacent discussion and again in the coding round. Learn the sliding-window-log, sliding-window-counter, token-bucket, and leaky-bucket approaches and when to use each.
  5. For the coding rounds, talk before you type. The interviewers are patient but they want to hear the tradeoffs before they see the code. I lost a little ground in round 1 by diving in too fast and had to rewind my approach.
  6. Have one good hiring-manager story about getting something wrong. The "what would you do differently" question came up in both the HM round and the behavioral portion of round 4. Vague answers read as canned.

Snowflake's loop was one of the more focused I did this cycle. Nothing about it felt performative, and the bar is high without being cruel. Good luck to anyone preparing.