Snowflake Data Scientist Interview Guide

Snowflake prices its platform on consumption, not seats. That single fact reshapes what data science looks like here. Your churn model doesn't just flag risk; it influences whether a customer scales up credit usage or quietly winds down, and that delta flows straight into quarterly product revenue.

Snowflake Data Scientist Role

Data scientists at Snowflake own problems from scoping through deployment, building churn propensity scores that surface directly in Salesforce workflows for Customer Success, running causal inference on Cortex AI feature rollouts, and presenting precision-recall tradeoffs to GTM leaders via Streamlit prototypes. Year-one success means a scoring system that's live in production and tied to a measurable shift in net revenue retention, not a research notebook.

A Typical Week

The surprise isn't the modeling time. It's how much of your week goes to storytelling, documentation, and fielding Slack questions from CSMs who need help interpreting a probability threshold. Expect your Tuesday deep-work block to get interrupted by ad-hoc SQL requests from the GTM analytics lead more often than you'd like.

Projects & Impact Areas

Churn propensity modeling anchors the work, where you're engineering features from rolling engagement decay patterns in dbt-transformed usage tables, then calibrating score thresholds that balance catching at-risk accounts against false-alarm fatigue for CSMs. That feeds into a broader experimentation practice around Cortex AI and Snowpark adoption, measuring whether new platform features cause incremental consumption or just redistribute existing workloads. Pricing sensitivity studies and cohort-level usage forecasting round out the portfolio, tying everything back to SaaS metrics like net revenue retention and expansion revenue.

Skills & What's Expected

SQL optimization on Snowflake's MPP architecture is the most underrated skill for this role. Candidates over-index on ML algorithm knowledge while underestimating how much the job requires reasoning about partition pruning, data distribution keys, and avoiding cross-cluster shuffles. Business acumen scores just as high as math/stats in the skill profile, which reflects a real expectation: if you can't explain why a 2-point lift in model precision changes how CSMs allocate their bandwidth, you'll plateau fast.

Levels & Career Growth

The jump from mid-level to senior at Snowflake hinges on owning problem framing across teams, not just executing well-scoped tasks. Staff-level roles require you to shape the analytical agenda and influence product roadmaps for features like Cortex AI. From there, the path forks: lean into Snowpark and ML infrastructure toward an ML engineering track, or lean into GTM analytics and executive storytelling toward product analytics leadership.

Work Culture

Most DS roles follow a structured hybrid model with three days in-office expected, though distributed teams get more remote flexibility. The pace is intense and accountability-driven, shaped by public-company growth pressure and the competitive race against Databricks. On the upside, Snowflake's culture rewards shipping over performing busyness, and data scientists are expected to deploy their own work rather than hand off notebooks to a separate engineering team.

Snowflake Data Scientist Compensation

Snowflake RSUs vest over four years with a one-year cliff, then shift to quarterly vesting. That first year without any equity hitting your account is real, so factor the cliff into how you evaluate your total first-year cash when comparing offers.

RSU grants carry more negotiation flexibility than base salary, from what candidates report. If you have a competing offer, lead with it when discussing equity. The single biggest lever most people leave on the table: asking whether a sign-on component can offset that year-one cliff. You won't know unless you raise it directly.

Snowflake Data Scientist Interview Process

The full loop spans about three weeks. Weak SQL is one of the most common rejection reasons, and the SQL & Data Modeling round is where it bites hardest. That round covers schema design, query optimization, and data warehousing concepts specific to Snowflake's architecture, so candidates who only practice standard joins and window functions tend to struggle when asked to justify modeling choices or tune queries for large-scale analytical workloads.

The behavioral round acts as a gate, not a formality. Snowflake's culture prizes ownership, meaning interviewers are screening for stories where you shipped end-to-end, from problem scoping through deployment and stakeholder communication. A strong technical performance across six rounds won't save you if your behavioral answers paint a picture of someone who builds models in isolation and hands off notebooks.

Snowflake Data Scientist Interview Questions

/*
Assumptions:
  - Table: ANALYTICS.EVENTS(account_id, user_id, event_ts, event_name)
  - event_ts is a timestamp in a consistent timezone for reporting
  - You want the last 30 calendar days including today
*/

WITH params AS (
  SELECT
    CURRENT_DATE() AS end_dt,
    DATEADD('day', -29, CURRENT_DATE()) AS start_dt
),
-- Build a 30 day date spine
calendar AS (
  SELECT
    DATEADD('day', seq4(), p.start_dt) AS day_dt
  FROM params p,
  TABLE(GENERATOR(ROWCOUNT => 30))
),
-- Limit scan to the relevant time range
filtered_events AS (
  SELECT
    account_id,
    user_id,
    CAST(event_ts AS DATE) AS day_dt
  FROM ANALYTICS.EVENTS e
  JOIN params p
    ON e.event_ts >= p.start_dt
   AND e.event_ts < DATEADD('day', 1, p.end_dt)
),
accounts AS (
  SELECT DISTINCT account_id
  FROM filtered_events
),
account_days AS (
  SELECT a.account_id, c.day_dt
  FROM accounts a
  CROSS JOIN calendar c
),
-- Aggregate DAU, preserving zero days
account_dau AS (
  SELECT
    ad.account_id,
    ad.day_dt,
    COUNT(DISTINCT fe.user_id) AS dau
  FROM account_days ad
  LEFT JOIN filtered_events fe
    ON fe.account_id = ad.account_id
   AND fe.day_dt = ad.day_dt
  GROUP BY 1, 2
)
SELECT
  account_id,
  day_dt,
  dau,
  AVG(dau) OVER (
    PARTITION BY account_id
    ORDER BY day_dt
    ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
  ) AS dau_7d_rolling_avg
FROM account_dau
ORDER BY account_id, day_dt;

/*
Goal:
  - One row per (account_id, week_start)
  - tickets_28d: count of tickets created in the trailing 28 days ending at week_end
  - dau_28d: sum of daily active users in the trailing 28 days ending at week_end

Assumptions:
  - ANALYTICS.EVENTS(account_id, user_id, event_ts)
  - SUPPORT.TICKETS(account_id, ticket_id, created_ts)
  - Week is Monday-based; adjust DATE_TRUNC('WEEK', ...) if your definition differs
*/

WITH params AS (
  SELECT
    CURRENT_DATE() AS end_dt,
    DATEADD('day', -180, CURRENT_DATE()) AS start_dt  -- lookback window for feature generation
),
-- Build weekly spine for accounts seen in either source
accounts AS (
  SELECT account_id
  FROM (
    SELECT DISTINCT account_id
    FROM ANALYTICS.EVENTS e
    JOIN params p
      ON e.event_ts >= p.start_dt
     AND e.event_ts < DATEADD('day', 1, p.end_dt)

    UNION

    SELECT DISTINCT account_id
    FROM SUPPORT.TICKETS t
    JOIN params p
      ON t.created_ts >= p.start_dt
     AND t.created_ts < DATEADD('day', 1, p.end_dt)
  )
),
weeks AS (
  SELECT
    DATEADD('week', seq4(), DATE_TRUNC('week', p.start_dt)) AS week_start
  FROM params p,
  TABLE(GENERATOR(ROWCOUNT => 30))
  QUALIFY week_start <= DATE_TRUNC('week', (SELECT end_dt FROM params))
),
account_weeks AS (
  SELECT a.account_id, w.week_start, DATEADD('day', 6, w.week_start) AS week_end
  FROM accounts a
  CROSS JOIN weeks w
),
-- Pre-aggregate EVENTS to account-day DAU
account_day_dau AS (
  SELECT
    account_id,
    CAST(event_ts AS DATE) AS day_dt,
    COUNT(DISTINCT user_id) AS dau
  FROM ANALYTICS.EVENTS e
  JOIN params p
    ON e.event_ts >= DATEADD('day', -28, p.start_dt)  -- extra headroom for trailing windows
   AND e.event_ts < DATEADD('day', 1, p.end_dt)
  GROUP BY 1, 2
),
-- Pre-aggregate TICKETS to account-day ticket counts
account_day_tickets AS (
  SELECT
    account_id,
    CAST(created_ts AS DATE) AS day_dt,
    COUNT(*) AS tickets
  FROM SUPPORT.TICKETS t
  JOIN params p
    ON t.created_ts >= DATEADD('day', -28, p.start_dt)
   AND t.created_ts < DATEADD('day', 1, p.end_dt)
  GROUP BY 1, 2
),
-- Date spine for the full range used by windows
calendar AS (
  SELECT
    DATEADD('day', seq4(), DATEADD('day', -28, (SELECT start_dt FROM params))) AS day_dt
  FROM TABLE(GENERATOR(
    ROWCOUNT => DATEDIFF('day', DATEADD('day', -28, (SELECT start_dt FROM params)), (SELECT end_dt FROM params)) + 1
  ))
),
-- Dense daily fact table per account, keeps joins stable and windows simple
account_day AS (
  SELECT
    a.account_id,
    c.day_dt,
    COALESCE(d.dau, 0) AS dau,
    COALESCE(t.tickets, 0) AS tickets
  FROM accounts a
  CROSS JOIN calendar c
  LEFT JOIN account_day_dau d
    ON d.account_id = a.account_id
   AND d.day_dt = c.day_dt
  LEFT JOIN account_day_tickets t
    ON t.account_id = a.account_id
   AND t.day_dt = c.day_dt
),
-- Compute trailing 28 day sums at the daily grain
account_day_windows AS (
  SELECT
    account_id,
    day_dt,
    SUM(dau) OVER (
      PARTITION BY account_id
      ORDER BY day_dt
      ROWS BETWEEN 27 PRECEDING AND CURRENT ROW
    ) AS dau_28d,
    SUM(tickets) OVER (
      PARTITION BY account_id
      ORDER BY day_dt
      ROWS BETWEEN 27 PRECEDING AND CURRENT ROW
    ) AS tickets_28d
  FROM account_day
)
SELECT
  aw.account_id,
  aw.week_start,
  w.dau_28d,
  w.tickets_28d
FROM account_weeks aw
JOIN account_day_windows w
  ON w.account_id = aw.account_id
 AND w.day_dt = aw.week_end
ORDER BY aw.account_id, aw.week_start;

import numpy as np
import pandas as pd


def daily_warehouse_metrics(df: pd.DataFrame) -> pd.DataFrame:
    """Compute daily per-warehouse latency percentiles and cost efficiency.

    Parameters
    ----------
    df : pd.DataFrame
        Columns: query_id, warehouse_name, start_time, end_time, bytes_scanned, compute_credits

    Returns
    -------
    pd.DataFrame
        Indexed by [day, warehouse_name] with columns:
        p50_duration_s, p95_duration_s, total_bytes_scanned, total_compute_credits, credits_per_TB
    """
    required = {
        "query_id",
        "warehouse_name",
        "start_time",
        "end_time",
        "bytes_scanned",
        "compute_credits",
    }
    missing = required - set(df.columns)
    if missing:
        raise ValueError(f"Missing columns: {sorted(missing)}")

    x = df.copy()

    # Parse timestamps and drop incomplete records.
    x["start_time"] = pd.to_datetime(x["start_time"], utc=True, errors="coerce")
    x["end_time"] = pd.to_datetime(x["end_time"], utc=True, errors="coerce")
    x = x.dropna(subset=["start_time", "end_time", "warehouse_name"]).copy()

    # Duration in seconds.
    duration_s = (x["end_time"] - x["start_time"]).dt.total_seconds()
    x["duration_s"] = duration_s

    # Keep only non-negative durations.
    x = x.loc[x["duration_s"].notna() & (x["duration_s"] >= 0)].copy()

    # Normalize numeric columns.
    x["bytes_scanned"] = pd.to_numeric(x["bytes_scanned"], errors="coerce").fillna(0.0)
    x["compute_credits"] = pd.to_numeric(x["compute_credits"], errors="coerce").fillna(0.0)

    # Day bucket from start_time.
    x["day"] = x["start_time"].dt.floor("D")

    def q(p: float):
        return lambda s: float(np.nanquantile(s.to_numpy(dtype=float), p)) if len(s) else np.nan

    agg = (
        x.groupby(["day", "warehouse_name"], as_index=True)
        .agg(
            p50_duration_s=("duration_s", q(0.50)),
            p95_duration_s=("duration_s", q(0.95)),
            total_bytes_scanned=("bytes_scanned", "sum"),
            total_compute_credits=("compute_credits", "sum"),
        )
        .sort_index()
    )

    # credits_per_TB, guard against divide by zero.
    tb = agg["total_bytes_scanned"] / 1e12
    agg["credits_per_TB"] = np.where(tb > 0, agg["total_compute_credits"] / tb, np.nan)

    return agg

from __future__ import annotations

import numpy as np
import pandas as pd


def make_churn_dataset(
    usage_daily: pd.DataFrame,
    accounts: pd.DataFrame,
    reference_day: str | pd.Timestamp,
    lookback_days: int = 28,
    label_horizon_days: int = 30,
) -> tuple[pd.DataFrame, pd.Series]:
    """Create leakage-safe features for churn modeling.

    Features are computed strictly from days in [t - lookback_days, t).
    Label is 1 if churn_date is in (t, t + label_horizon_days].

    Parameters
    ----------
    usage_daily : pd.DataFrame
        Columns: account_id, day, queries, active_users
    accounts : pd.DataFrame
        Columns: account_id, plan, region, churn_date
    reference_day : str or pd.Timestamp
        The cutoff day t.
    lookback_days : int
        Number of days to look back for features.
    label_horizon_days : int
        Number of days after t to look for churn.

    Returns
    -------
    X : pd.DataFrame
        Feature matrix indexed by account_id.
    y : pd.Series
        Binary label indexed by account_id.
    """
    # Validate columns.
    req_usage = {"account_id", "day", "queries", "active_users"}
    req_acct = {"account_id", "plan", "region", "churn_date"}
    if req_usage - set(usage_daily.columns):
        raise ValueError(f"usage_daily missing: {sorted(req_usage - set(usage_daily.columns))}")
    if req_acct - set(accounts.columns):
        raise ValueError(f"accounts missing: {sorted(req_acct - set(accounts.columns))}")

    t = pd.to_datetime(reference_day).normalize()
    start = t - pd.Timedelta(days=lookback_days)
    end_exclusive = t

    u = usage_daily.copy()
    u["day"] = pd.to_datetime(u["day"]).dt.normalize()

    # Enforce the feature window: [start, t).
    u = u.loc[(u["day"] >= start) & (u["day"] < end_exclusive)].copy()

    # Numeric hygiene.
    u["queries"] = pd.to_numeric(u["queries"], errors="coerce").fillna(0.0)
    u["active_users"] = pd.to_numeric(u["active_users"], errors="coerce").fillna(0.0)

    # Aggregate features over the lookback window.
    feats = (
        u.groupby("account_id", as_index=True)
        .agg(
            queries_28d_sum=("queries", "sum"),
            queries_28d_mean=("queries", "mean"),
            active_users_28d_mean=("active_users", "mean"),
            active_days_28d=("day", "nunique"),
        )
        .astype(float)
    )

    # Add simple trend feature using first vs last 7 days.
    u["day_offset"] = (u["day"] - start).dt.days
    last7_cut = lookback_days - 7

    first7 = (
        u.loc[u["day_offset"] < 7]
        .groupby("account_id")["queries"]
        .mean()
        .rename("queries_first7_mean")
    )
    last7 = (
        u.loc[u["day_offset"] >= last7_cut]
        .groupby("account_id")["queries"]
        .mean()
        .rename("queries_last7_mean")
    )
    feats = feats.join(first7, how="left").join(last7, how="left")
    feats["queries_7d_trend"] = feats["queries_last7_mean"] - feats["queries_first7_mean"]
    feats = feats.drop(columns=["queries_first7_mean", "queries_last7_mean"])

    # Join static account attributes.
    a = accounts.copy()
    a["churn_date"] = pd.to_datetime(a["churn_date"], errors="coerce").dt.normalize()
    a = a.set_index("account_id")

    X = feats.join(a[["plan", "region"]], how="left")

    # Label uses churn_date strictly after t and within horizon.
    churn_in_window = (a["churn_date"] > t) & (a["churn_date"] <= (t + pd.Timedelta(days=label_horizon_days)))
    y = churn_in_window.astype(int).rename("churn_30d")

    # Align y to X (only accounts with feature history).
    y = y.reindex(X.index).fillna(0).astype(int)

    # One-hot encode categorical columns.
    X = pd.get_dummies(X, columns=["plan", "region"], dummy_na=True)

    # Final cleanup.
    X = X.replace([np.inf, -np.inf], np.nan).fillna(0.0)

    return X, y

Snowflake's distribution is unusually flat across five technical areas, with no single topic dominating above 22%. That shape rewards breadth over depth and punishes the candidate who spends all their prep time on sklearn classifiers while neglecting the causal inference and experimentation questions that, together, account for roughly a quarter of the loop. The sample questions in the widget reveal a consistent pattern: they're grounded in Snowflake-specific artifacts (credit consumption, warehouse provisioning, Snowpark activation funnels), so you'll need to reason about the mechanics of a consumption-based platform, not just recite textbook methods.

Practice these question types, weighted to match Snowflake's actual interview mix, at datainterview.com/questions.

How to Prepare for Snowflake Data Scientist Interviews

Snowflake's north star right now is making enterprise data AI-ready by design. Product launches like Cortex Code, Semantic View, and Autopilot all point in the same direction: owning the path from raw data to AI inference inside one platform. Snowflake Postgres extends that ambition into transactional data, pulling workloads that previously lived outside the warehouse into Snowflake's ecosystem.

The financials frame the stakes. FY2025 revenue came in around $4.4B, up 28.7% year over year, yet market cap slipped about 5.4% over the same period. That gap between strong top-line growth and a skeptical stock price is where data scientists sit: every experiment measuring whether Cortex or Autopilot drives incremental credit consumption feeds directly into the narrative Snowflake needs to tell investors.

Most candidates blow their "why Snowflake" answer by talking about scale or the data cloud in abstract terms. What actually resonates is showing you understand that Snowflake's consumption-based pricing means a churn propensity model doesn't just save an account, it protects a stream of credit usage that compounds quarter over quarter. Name a specific product surface (Cortex AI functions, Snowpark ML pipelines) and describe the metric you'd use to evaluate whether it moves net revenue retention, not just user adoption.

Try a Real Interview Question

| TABLE: USER_ACTIVITY |
| user_id | activity_date | event_type |
|---------|---------------|------------|
| U1      | 2024-01-02    | login      |
| U1      | 2024-02-01    | query      |
| U2      | 2024-01-10    | login      |
| U2      | 2024-01-20    | query      |
| U3      | 2024-02-05    | login      |

| TABLE: DATE_DIM |
| dt         |
|------------|
| 2024-02-01 |
| 2024-02-02 |
| 2024-02-03 |
| 2024-02-04 |
| 2024-02-05 |

WITH activity AS (
  SELECT DISTINCT
    user_id,
    TO_DATE(activity_date) AS activity_date
  FROM user_activity
),
users AS (
  SELECT DISTINCT user_id
  FROM activity
),
dates AS (
  SELECT TO_DATE(dt) AS dt
  FROM date_dim
),
base AS (
  SELECT
    d.dt,
    u.user_id,
    /* active in the prior 28 days ending on d */
    IFF(EXISTS (
      SELECT 1
      FROM activity a
      WHERE a.user_id = u.user_id
        AND a.activity_date BETWEEN DATEADD(day, -27, d.dt) AND d.dt
    ), 1, 0) AS active_prev_28,
    /* any activity in the next 28 days after d */
    IFF(EXISTS (
      SELECT 1
      FROM activity a
      WHERE a.user_id = u.user_id
        AND a.activity_date BETWEEN DATEADD(day, 1, d.dt) AND DATEADD(day, 28, d.dt)
    ), 1, 0) AS active_next_28,
    /* any activity in the next 7 days after d (for return) */
    IFF(EXISTS (
      SELECT 1
      FROM activity a
      WHERE a.user_id = u.user_id
        AND a.activity_date BETWEEN DATEADD(day, 1, d.dt) AND DATEADD(day, 7, d.dt)
    ), 1, 0) AS active_next_7
  FROM dates d
  CROSS JOIN users u
),
labeled AS (
  SELECT
    dt,
    user_id,
    IFF(active_prev_28 = 1 AND active_next_28 = 0, 1, 0) AS is_churned,
    IFF(active_prev_28 = 1 AND active_next_28 = 0 AND active_next_7 = 1, 1, 0) AS returned_within_7d
  FROM base
)
SELECT
  dt AS churn_date,
  SUM(is_churned) AS churned_users,
  SUM(returned_within_7d) AS returned_within_7d
FROM labeled
GROUP BY 1
ORDER BY 1;

Snowflake's SQL rounds focus on how queries behave on their micro-partition architecture, where writing correct SQL is table stakes and the real test is whether you can reason about clustering keys and partition pruning to avoid full-table scans. Practice problems tuned for warehouse-specific optimization at datainterview.com/coding.

Test Your Readiness

Run through Snowflake DS practice questions at datainterview.com/questions to spot gaps across ML, experimentation, product sense, and causal inference before your loop starts.