Site Reliability Engineer Interview Experience at Snowflake – 2026

The hiring manager opens directly with this round rather than a separate recruiter screen, asking about current infrastructure ownership and specifically what scale of system was operated (request volume, team size supporting it) to gauge level fit before scheduling further rounds.

This coding round focuses on concurrency, asking candidates to implement a thread-safe LRU cache supporting concurrent reads and writes without a single global lock serializing all access. A sharded-lock approach — partitioning the cache's key space across multiple independent locks so operations on different shards can proceed concurrently — is the expected direction, along with discussion of the tradeoff that this makes a true global eviction-order guarantee harder to maintain exactly, an acceptable approximation for most caching use cases.

This second coding round has a data-processing flavor: given a stream of query execution log entries, compute a rolling P99 execution time per warehouse (Snowflake's term for a compute cluster) over a trailing time window. A per-warehouse sorted structure of recent execution times, evicting entries older than the window on each new arrival, is a solid approach, along with discussing the tradeoff of approximate percentile structures (like t-digest) for very high-cardinality warehouses where exact sorted-structure maintenance becomes expensive.

Candidates are asked to design a resource-scheduling service for allocating compute warehouses to incoming queries, where workload demand is highly bursty (many queries queuing during business hours, near-idle overnight) and different customers have different priority tiers. Starting explicitly from a requirements breakdown — clarifying whether starvation of low-priority queries during sustained high load is acceptable — before proposing a priority-weighted fair-queueing model with a minimum-guaranteed-throughput floor even for the lowest tier is the strong approach, avoiding a lower-priority customer being starved indefinitely during a sustained burst from higher-priority tenants. A common follow-up probes how to handle a customer's priority tier changing mid-query, addressed by having priority apply only at scheduling time, not retroactively to an already-running query.