Interviews by company · Snowflake

Snowflake lets you use AI in the phone screen, then grades how you gathered the requirements and proved the code.

Snowflake's software engineer technical phone screen is sixty minutes in CoderPad, Python, with AI allowed. The recruiter's framing, as one candidate relayed it: the evaluation is how you gather requirements, test and debug. The AI Engineer onsite goes further with an in-person round the company calls AI Augmented coding, where you bring your own laptop and assistant and the assistant may write the code. Both reports we read, from late September 2026, got the same task: a rate limiter with client tiers whose limits change at runtime. Here is what the rounds are, what the follow-ups asked, and where the reported candidate lost points.

What the rounds look like

The phone screen is a shared CoderPad, an hour, Python. The prompt is spoken, and short: build a rate limiting service with tiers, let the limits change at runtime, enforce the right limit per client, reject over it. The interviewer then adds the fallback rule out loud: a client nobody configured, or a broken configuration, falls back to a global default policy, and both default-deny and default-approve are fine as long as you pick one. You are expected to ask what is missing before you write.

The onsite round for AI Engineer roles is in person. You bring a laptop with whatever assistant you like already set up. The reported prompt was the classic design and implement a rate limiter; the assistant may write the code, and the candidate explains the algorithm they chose, what else they considered and why not, and then how they prompted, what they reviewed and what they tested.

What the follow-ups are really about

The phone-screen follow-ups came in a fixed order. Why this algorithm, and the pros and cons of each alternative. Add tests that prove it runs. The real clock is too fast for a bucket to refill between two calls, so how do you test refill: the answer they wanted was to inject a clock or, less elegantly, to sleep. Then the step up: everything is in memory on one instance, how does this become a distributed cluster. The candidate ran out of time before that one.

Our read: the task is small on purpose, and the round is a requirements and verification exercise with a rate limiter as the prop. Two details the reported candidate got wrong are the ones a careful reading of their own design would have caught: raising a tier's limit changes the ceiling, not the tokens a bucket already holds; and refill is time elapsed times the rate, not times the capacity. Both are the kind of thing an assistant will happily get wrong in confident code.

What is confirmed, and what is not

  • Confirmed: AI allowed in the software engineer phone screen (CoderPad, Python, 60 minutes); an in-person AI Augmented coding round in the AI Engineer onsite; the rate limiter as the task in both; the runtime-update requirement and the default policy; the clock-injection follow-up.
  • Reported once: the recruiter's framing of the evaluation; the exact order of the follow-ups; the two question types of the onsite round; the distributed-systems follow-up as the one that ran out of time.
  • Not known: which assistant the phone screen provides, if any, beyond what the candidate brings; whether the same task is used for other roles; how the phone screen weighs against the onsite.

How we would prepare

  • Ask the fallback question yourself. What happens to a client with no tier, or a tier that was deleted? The interviewer added it out loud; saying it first is the requirements-gathering they grade.
  • Know what a runtime update does to live state. Decide, and say, whether a raised limit adds tokens now or only raises the ceiling, and whether a cut clamps. The reported candidate lost this one.
  • Inject the clock before you are asked. A limiter that takes a time source is testable without sleeping; the follow-up is asking whether you built it that way.
  • Have the distributed answer ready in two sentences. A shared store with an atomic check-and-decrement, and what you lose when the store is down. It was the follow-up nobody reached.
  • Read the assistant's refill arithmetic. Elapsed time times the rate, clamped at capacity. It is one line, and it is where the generated code goes wrong.

Nyrion's Snowflake section starts with Tiered Rate Limiter, built from these reports: client tiers with buckets, limits that change at runtime with the settle-then-apply rule spelled out, a default policy for unconfigured clients, and a fake clock in the tests so refill is checked the way the follow-up asks. A third stage adds a shared downstream capacity that must never be exceeded, from a related exercise. The tiers, the runtime updates, the default policy and the clock question are what candidates describe; the exact API, the numbers and the shared-capacity stage are ours.

How this round compares with other companies' versions, and what every version grades: the AI coding interview guide.

Frequently asked, briefly answered

Which Snowflake rounds allow AI?

Two are reported. The software engineer technical phone screen: sixty minutes in CoderPad, Python, AI allowed, with the recruiter framing the evaluation as how you gather requirements, test and debug. And an in-person round in the AI Engineer onsite the company calls AI Augmented coding: bring your own laptop with any assistant preinstalled.

What was the task?

A rate limiting service in both reports. The phone-screen prompt, in the candidate's words: different clients have different tiers such as free, pro and enterprise; the limits for each tier can be updated at runtime without restarting; a request carries a client identifier and the service enforces the tier's limit; over the limit, reject. Spoken addition: a client with no tier, or a broken configuration, falls back to a global default policy.

What did the follow-ups ask?

In order, from the phone-screen report: why this algorithm and the pros and cons of the alternatives; tests that prove it runs; how you test the refill when the real clock is too fast between calls (inject a clock, or sleep); and how a single in-memory instance evolves into a distributed cluster. The onsite report adds: how you prompted, reviewed and tested what the assistant wrote.

Where did the reported candidate lose points?

Two lessons the candidate wrote down afterwards: raising a tier's limit does not add tokens to existing buckets, capacity is only the ceiling; and refill is elapsed time times the refill rate, not times the capacity. They finished the implementation and the tests and ran out of time before the distributed-systems follow-up. Rejected.

Does the assistant write the code?

In the onsite round it may. The candidate still has to explain the algorithm chosen, the alternatives and the trade-offs, then walk through how they prompted, reviewed and tested. In the phone screen, AI is allowed alongside your own typing.

Practice problems tagged for Snowflake

Browse the catalog and open the Snowflake section. No login required to look; sign in when you want to solve one.