What is Category 3: Cost Management & Credits?

Q8. Scenario: Your Snowflake credits spiked 3x last Tuesday vs. the previous Tuesday. How do you diagnose this? This is a real operational scenario and interviewers love it because it tests whether you know ACCOUNT_USAGE views. This immediately tells you which warehouse(s) were responsible. Look for: unusually long execution times, massive bytes_scanned values, or high bytes_spilled_to_remote_storage — all signals of expensive queries.

Snowflake Interview Questions

After all of this, the real tell at the senior level isn’t whether you know all these answers. It’s whether you can connect them. The best signal a

After all of this, the real tell at the senior level isn’t whether you know all these answers. It’s whether you can connect them.

The best signal a senior candidate gives is when they answer one question and naturally reference another. “That’s the same clustering depth issue I mentioned earlier — the root cause is the same even though the symptoms look different.” That kind of connected thinking is what separates someone who’s read about Snowflake from someone who’s been debugging production issues at midnight.

These aren’t different topics. They’re the same platform, looked at from different angles. That’s what the senior interview is actually testing.

Good luck — and if any of these scenarios show up in your interview and you crack it, come back and let me know.

I’ve been on both sides of the Snowflake interview table now. I’ve been the nervous one trying to remember what CLUSTER_BY actually does under pressure, and I’ve been the one reviewing candidates who clearly memorized a blog post instead of actually understanding the platform.

There’s a massive gap between what the generic “Top 50 Snowflake Interview Questions” articles prepare you for and what a senior data engineering interview actually feels like. This article is about that gap.

Nobody at the senior level is going to ask you “what is a virtual warehouse.” What they’re going to do is describe a production scenario — something that went wrong, or a design problem they’re genuinely wrestling with — and see how you think through it. They want to know if you’ve actually been inside the query profile. If you’ve ever had a Snowpipe backlog and had to figure out why. If you understand what “spilling to remote storage” means for your credit bill.

This is the article I wish existed when I was preparing. I’m writing it from everything I’ve learned building real things on Snowflake — not from documentation tabs.

How to Read This Article

I’ve organized questions into six categories that match how real interviews are structured:

Architecture & Internals
Performance Tuning & Query Optimization
Cost Management & Credits
Data Ingestion & Pipelines
Security, Governance & RBAC
Real-World Scenario Questions (the hardest ones)

Each question comes with what a strong answer actually sounds like — not bullet points you memorize, but the kind of connected thinking that signals you’ve done this for real.

Category One: Architecture & Internals

These questions separate people who’ve read the docs from people who understand the engine.

Q1. Walk me through what actually happens when a query hits Snowflake — from the moment I press Run to the moment results appear.

This is the architecture question that trips up even experienced people because they know the three layers but can’t connect them into a real execution story.

A strong answer: When you submit a query, it first hits the Cloud Services layer — this is Snowflake’s brain. It authenticates you, parses the SQL, checks metadata in the global metadata store (which knows exactly which micro-partitions hold your data without touching a warehouse), and builds a query execution plan. This whole step runs without your virtual warehouse even waking up.

If the results of this exact query are already in the result cache — and the underlying data hasn’t changed — Snowflake returns those results instantly from Cloud Services. Zero warehouse credits consumed. This is why identical repeated queries on unchanged data are free.

If there’s no cached result, the query gets dispatched to your virtual warehouse — the compute layer. The warehouse spins up worker nodes (if suspended, there’s a small cold-start cost), and each node fetches the relevant micro-partitions from cloud storage — S3, Azure Blob, or GCS. This data gets loaded into the warehouse’s local SSD cache (the local disk cache). The workers process it in parallel using MPP (Massively Parallel Processing), and results flow back to the Cloud Services layer, which caches them in the result cache, then returns them to you.

The key insight: storage is completely decoupled from compute. Multiple warehouses can read the same data simultaneously without contention. This is the fundamental reason Snowflake handles concurrent workloads better than traditional MPP databases.

Q2. Explain micro-partitioning. How does it actually affect query performance and what can go wrong?

Snowflake automatically divides table data into micro-partitions — immutable, compressed columnar files, typically between 50 and 500 MB of uncompressed data. Each micro-partition stores metadata: min and max values for each column, number of distinct values, null counts.

When a query runs with a WHERE clause, Snowflake uses this metadata to prune micro-partitions — skipping any partition where the filter condition can’t possibly match. If your query is WHERE order_date = '2024-01-15', Snowflake checks the min/max metadata on order_date for each micro-partition and skips any partition where 2024-01-15 is outside that range. It never reads those partitions.

The failure mode: if data is poorly clustered — meaning order_date values are scattered randomly across hundreds of micro-partitions — pruning becomes ineffective. Snowflake has to read most of the table to find your rows. This is when you see large “Bytes scanned” numbers in the query profile despite a tight filter.

Check clustering health with:

SELECT SYSTEM$CLUSTERING_INFORMATION(
    'orders',
    '(order_date)'
);

Look at average_depth. A value close to 1.0 means excellent pruning. Higher values mean data is scattered and clustering is poor.

What can make clustering degrade over time: heavy DML operations (lots of individual INSERTs or UPDATEs) scatter data across new micro-partitions without regard to clustering order. For tables that receive continuous small inserts, consider a Clustering Key with automatic reclustering enabled.

Q3. What is the difference between Automatic Clustering and manually running CLUSTER BY?

When you define a clustering key on a table, Snowflake can maintain it in two ways.

Manually triggering ALTER TABLE orders CLUSTER BY (order_date) runs a one-time reclustering operation. It reorganizes existing micro-partitions to improve clustering depth on the specified column. It costs credits and is a point-in-time fix.

Automatic Clustering is a continuous background service. Once enabled, Snowflake monitors clustering depth and automatically triggers reclustering operations when it detects degradation — typically after significant DML activity. You pay for the compute, but you don’t manage it.

When should you use automatic clustering vs. not? Automatic clustering makes sense for large tables (generally multi-TB+) that receive continuous writes and are frequently queried with filters on a high-cardinality column. For smaller tables, or tables that are mostly read-only after initial load, the cost of continuous clustering may not justify the query performance improvement. Always benchmark before enabling it.

A practical note: clustering keys should have high cardinality (lots of distinct values) but not too high — date columns, category columns with dozens of values, and region columns are good candidates. Using a UUID or primary key as a clustering key is usually a mistake — too many distinct values means micro-partitions can’t contain meaningful ranges.

Q4. Describe the three types of caching in Snowflake and the situations where each one helps you — or fails you.

This is a question where depth matters more than breadth.

Result Cache (Cloud Services layer): Stores the complete output of recent queries for up to 24 hours. If you run the same query and the underlying data hasn’t changed, you get the result back instantly with zero warehouse compute. The “data hasn’t changed” check is metadata-based — if any DML touched the relevant tables, the result cache is invalidated.

Where it fails: if your query uses non-deterministic functions like CURRENT_TIMESTAMP(), RANDOM(), or CURRENT_USER() — or if a WHERE clause references CURRENT_DATE() — the result cache is bypassed entirely because the result could differ on each execution. This is a common gotcha: wrapping a query in a scheduled task that adds WHERE load_date = CURRENT_DATE() means the result cache never kicks in.

Local Disk Cache (Warehouse layer): When worker nodes fetch micro-partitions from cloud storage, they cache them on local SSD. Subsequent queries that touch the same micro-partitions within the same warehouse session can read from local disk rather than going back to object storage — significantly faster. This cache is per-warehouse and is lost when the warehouse suspends.

Where it fails: if you suspend your warehouse and resume it, the local cache is cold. For dashboards or BI tools that run queries on a fixed schedule against a specific warehouse, keeping that warehouse running between query bursts (or using auto-resume with a short suspend timeout) preserves the local cache and makes repeated runs faster.

Metadata Cache (Cloud Services layer): Snowflake maintains metadata about table structure, row counts, min/max values, and partition information entirely in memory in the Cloud Services layer. Many COUNT(*), MIN(), and MAX() queries on simple tables can be answered from metadata alone — without engaging a warehouse at all.

Where it helps the most: SELECT COUNT(*) FROM large_table that would cost credits on any other platform is often free on Snowflake.

Category 2: Performance Tuning & Query Optimization

Q5. You inherit a query that takes 45 minutes. Walk me through your exact diagnostic process.

A senior candidate’s answer is a structured diagnostic process, not a list of tips.

Step 1: Open the Query Profile. In Snowsight, find the query in query history and click into the profile. The profile shows you a DAG of query operators — where time was spent, which operator consumed the most credits, and critically: whether there was spillage.

Step 2: Check for spillage first. Look for “Bytes spilled to local storage” or “Bytes spilled to remote storage” in the query profile. Spillage means the warehouse ran out of memory and had to write intermediate results to disk. Remote spillage is particularly expensive — it means even local SSD wasn’t enough. This is your first escalation trigger. If you see remote spillage, the warehouse is too small for this query. Upsizing the warehouse (SMALL → MEDIUM → LARGE) doubles memory at each step and can eliminate spillage entirely. Upsizing isn’t always the right long-term answer, but it tells you quickly whether memory is the constraint.

Step 3: Check partition pruning. Look at “Partitions scanned” vs “Partitions total.” If the ratio is high (e.g., 2.4M / 2.5M partitions scanned), the query is doing a near-full table scan. This means either no clustering key, wrong clustering key, or the filter column isn’t selective. Add a filter on a well-clustered column, or reconsider the clustering key.

Step 4: Check for cartesian joins or bad join order. In the profile DAG, look at the row counts flowing between join operators. If an intermediate join is exploding rows to billions before a later filter reduces them, the query logic needs rewriting — push filters earlier or restructure CTEs.

Step 5: Check for repeated subqueries. A correlated subquery inside a CASE statement or a nested SELECT that re-executes per row is a classic SQL performance killer. Rewrite using window functions or pre-aggregated CTEs.

Step 6: Check the warehouse size vs. the data volume. Snowflake’s query optimizer makes different decisions at different warehouse sizes. An XL warehouse processes 16x the data per unit time as an XS. For one-off heavy queries, temporarily bumping to a larger warehouse is often cheaper (faster completion = fewer total credits) than running a smaller warehouse for much longer.

Q6. Scenario: A dbt model that was running in 8 minutes is now taking 35 minutes. Nothing in the SQL changed. What do you investigate?

This is the scenario that makes senior candidates shine because it forces them to think about things outside the SQL.

The first question I’d ask: did anything change in the data, even if the SQL didn’t change? If row volume doubled (new data source onboarded, historical backfill ran), the same query legitimately takes longer. Check row counts in the source tables against last month.

Second: did the warehouse change? If the warehouse was downsized or its MAX_CLUSTER_COUNT was reduced, the same query runs with less compute. Check warehouse history.

Third: clustering degradation. If the table receives continuous inserts and has a clustering key, clustering depth degrades over time as new micro-partitions are added in insertion order rather than cluster order. Run SYSTEM$CLUSTERING_INFORMATION and compare to a baseline. If average_depth climbed significantly, reclustering is overdue.

Fourth: check if a new index of activity appeared in QUERY_HISTORY around the same time the slowdown started. Sometimes a new workload hitting the same warehouse — a new analyst running heavy queries during your pipeline window — causes credit contention that slows your job. The fix is workload isolation: move the pipeline to a dedicated warehouse.

Fifth: run the query on a larger warehouse and compare. If it’s proportionally faster, it’s a compute-bound problem. If it’s not faster, it’s a data or SQL problem.

Q7. What is a multi-cluster warehouse, and when would you specifically choose NOT to use one?

A multi-cluster warehouse allows Snowflake to spin up additional warehouse clusters automatically when queuing occurs — concurrency scaling for a single warehouse. Instead of queries waiting in line because the single-cluster warehouse is at max concurrency, a second (or third, up to your max setting) cluster spins up to serve additional queries.

When to use it: high-concurrency workloads where many users or processes are querying simultaneously. BI tools with dozens of dashboards refreshing at the same time. ETL pipelines that run many parallel tasks. Anything where queries are frequently queuing.

When NOT to use it: for a single-user or low-concurrency workload, multi-cluster adds cost with no benefit — you’re paying for cluster management overhead. Also: multi-cluster doesn’t help a single slow query. One 45-minute query does not benefit from a second cluster spinning up because the bottleneck is compute for that one query, not concurrency. For that scenario, you want a larger single-cluster warehouse, not more clusters.

The billing nuance: each active cluster in a multi-cluster warehouse is billed separately. A MEDIUM warehouse running 3 clusters simultaneously costs 3x a single MEDIUM warehouse. This is appropriate and expected for high-concurrency workloads — but if multi-cluster is accidentally enabled on a warehouse that doesn’t need it, you’ll see credits spike unnecessarily.

Category 3: Cost Management & Credits

Q8. Scenario: Your Snowflake credits spiked 3x last Tuesday vs. the previous Tuesday. How do you diagnose this?

This is a real operational scenario and interviewers love it because it tests whether you know ACCOUNT_USAGE views.

-- Step 1: Identify which warehouses drove the spike
SELECT
    warehouse_name,
    DATE(start_time)            AS usage_date,
    SUM(credits_used)           AS total_credits
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time >= DATEADD('day', -14, CURRENT_TIMESTAMP())
GROUP BY warehouse_name, DATE(start_time)
ORDER BY usage_date, total_credits DESC;

This immediately tells you which warehouse(s) were responsible.

-- Step 2: Drill into queries on that warehouse during the spike window
SELECT
    query_id,
    query_text,
    user_name,
    warehouse_name,
    execution_time / 1000       AS execution_seconds,
    bytes_spilled_to_remote_storage,
    bytes_scanned,
    credits_used_cloud_services
FROM snowflake.account_usage.query_history
WHERE warehouse_name = 'TRANSFORM_WH'
  AND DATE(start_time) = '2024-01-16'
ORDER BY execution_time DESC
LIMIT 20;

Look for: unusually long execution times, massive bytes_scanned values, or high bytes_spilled_to_remote_storage — all signals of expensive queries. Also check if the number of queries is simply higher (new pipeline deployed, more users added).

-- Step 3: Check if a new pipeline or user caused the spike
SELECT
    user_name,
    COUNT(*) AS query_count,
    SUM(execution_time) / 1000 AS total_execution_seconds
FROM snowflake.account_usage.query_history
WHERE DATE(start_time) = '2024-01-16'
GROUP BY user_name
ORDER BY total_execution_seconds DESC;

Once you identify the culprit, add a Resource Monitor to prevent recurrence:

CREATE OR REPLACE RESOURCE MONITOR transform_wh_monitor
  WITH CREDIT_QUOTA = 500
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND_IMMEDIATE;

ALTER WAREHOUSE transform_wh SET RESOURCE_MONITOR = transform_wh_monitor;

Q9. What’s the practical difference between Transient and Permanent tables, and when would misusing them burn you?

Permanent tables have full Time Travel (up to 90 days) and a 7-day Fail-safe period after Time Travel expires. Both features consume storage — Snowflake keeps the historical micro-partitions for the retention window.

Transient tables have Time Travel capped at 1 day, and zero Fail-safe. They cost less storage because there’s no extended historical data being maintained.

When transient tables make sense: staging tables and intermediate transformation tables that you rebuild completely each run. If a table is truncated and reloaded daily, paying for 90 days of Time Travel on that data is pure waste.

The burn scenario: someone creates all their core business tables as transient to save costs. Then a developer runs DELETE FROM customer_dim WHERE segment = 'Enterprise' with a bug in the WHERE clause — and instead of filtering to test accounts, it deletes 40,000 live customer records. With a permanent table, you’d recover with a Time Travel query in 5 minutes. With a transient table, if this happened 2 days ago, that data is gone. Fail-safe doesn’t exist for transient tables. Recovery now means a full source-system re-extract and reload.

The right pattern: transient for staging and scratch tables. Permanent for anything that is a source of truth.

Category #4: Data Ingestion & Pipelines

Q10. You set up Snowpipe to ingest data from an S3 bucket. After two weeks it stops loading new files. Files are landing in S3 but not appearing in Snowflake. Walk me through your debugging process.

Snowpipe is event-driven — it relies on S3 event notifications (or Snowflake’s AUTO_INGEST) to trigger. If notifications stop firing, files pile up silently.

Step 1: Check the pipe status.

SELECT SYSTEM$PIPE_STATUS('my_schema.my_pipe');

Look at pendingFileCount, lastIngestedTimestamp, and executionState. If executionState is PAUSED or STOPPED, that’s your immediate answer.

Step 2: Check for load errors.

SELECT *
FROM TABLE(INFORMATION_SCHEMA.COPY_HISTORY(
    TABLE_NAME => 'target_table',
    START_TIME => DATEADD('day', -3, CURRENT_TIMESTAMP())
))
WHERE STATUS != 'Loaded'
ORDER BY LAST_LOAD_TIME DESC;

If files attempted to load and failed — schema mismatch, malformed JSON, wrong delimiter — Snowpipe silently skips them after the error threshold. Files that fail repeatedly get quarantined and stop triggering new notifications.

Step 3: Check SQS queue (for S3 auto-ingest).

For S3-triggered Snowpipe, Snowflake creates an SQS queue that receives S3 event notifications. If that SQS queue fills up (it has limits) or the S3 event notification configuration was accidentally removed, events stop flowing.

Step 4: Check file format.

If someone modified the source system’s file format — added a column, changed the delimiter from comma to pipe, switched from gzip to uncompressed — and the Snowpipe file format definition wasn’t updated, every new file fails silently.

Prevention: set up a monitoring query as a scheduled Snowflake Task that alerts when lastIngestedTimestamp hasn’t updated in more than X hours. Don’t wait for a stakeholder to notice missing data.

Q11. What is the difference between Streams and Tasks in Snowflake, and give me a real scenario where you’d use them together?

A Stream is a change data capture object. It sits on top of a table and tracks INSERT, UPDATE, and DELETE operations that occurred since the stream was last consumed. It doesn’t store data — it stores metadata about what changed and where those changed rows are. Querying a stream returns the rows that changed and a METADATA$ACTION column telling you whether they were INSERTed, UPDATEd (shows as DELETE + INSERT), or DELETEd.

A Task is a scheduled SQL executor. It runs a SQL statement on a schedule (cron-style) or as part of a task tree (dependency-based). Tasks can be configured to run only if a stream has data — this is the key integration.

Real scenario — SCD Type 2 on a customer dimension:

-- Stream on the raw customer table to capture changes
CREATE OR REPLACE STREAM customer_changes_stream
  ON TABLE raw.customers;

-- Task that runs every 15 minutes but only if stream has data
CREATE OR REPLACE TASK apply_scd2_changes
  WAREHOUSE = transform_wh
  SCHEDULE = '15 MINUTE'
  WHEN SYSTEM$STREAM_HAS_DATA('customer_changes_stream')
AS
  MERGE INTO dim_customers AS target
  USING (
      SELECT
          customer_id,
          customer_name,
          email,
          segment,
          METADATA$ACTION,
          METADATA$ISUPDATE
      FROM customer_changes_stream
      WHERE METADATA$ACTION = 'INSERT'
  ) AS changes
  ON target.customer_id = changes.customer_id
     AND target.is_current = TRUE
  WHEN MATCHED AND changes.METADATA$ISUPDATE = TRUE THEN
      UPDATE SET target.end_date = CURRENT_DATE(),
                 target.is_current = FALSE
  WHEN NOT MATCHED THEN
      INSERT (customer_id, customer_name, email, segment,
              start_date, end_date, is_current)
      VALUES (changes.customer_id, changes.customer_name,
              changes.email, changes.segment,
              CURRENT_DATE(), NULL, TRUE);

ALTER TASK apply_scd2_changes RESUME;

The WHEN SYSTEM$STREAM_HAS_DATA() condition is critical — it means the task doesn’t consume warehouse credits on runs where nothing changed. The task wakes up, checks the condition, finds the stream empty, and goes back to sleep. Only on runs where actual customer data changed does it spin up the warehouse and execute the MERGE.

Category Five: Security, Governance & RBAC

Q12. Your security team asks you to ensure that the analytics team can see a salary column in aggregate reports but cannot see individual employee salaries. How do you implement this in Snowflake?

This is a column-level security scenario. Snowflake has two tools here: Dynamic Data Masking and Secure Views.

The cleaner approach for this scenario is Dynamic Data Masking:

-- Create a masking policy
CREATE OR REPLACE MASKING POLICY mask_salary
  AS (val NUMBER) RETURNS NUMBER ->
    CASE
        WHEN CURRENT_ROLE() IN ('HR_ADMIN', 'SYSADMIN') THEN val
        ELSE NULL   -- Or return 0, or a rounded bucket
    END;

-- Apply it to the salary column
ALTER TABLE employees
  MODIFY COLUMN salary
  SET MASKING POLICY mask_salary;

Now anyone in HR_ADMIN sees actual salaries. Everyone else sees NULL in that column. The table structure is the same — no separate view to maintain, no duplication of logic across multiple views. The policy travels with the column.

For the aggregate-only requirement (they can see AVG(salary) but not individual values), a Secure View is the right tool:

CREATE OR REPLACE SECURE VIEW employee_salary_summary AS
SELECT
    department,
    job_grade,
    COUNT(*) AS headcount,
    ROUND(AVG(salary), -3) AS avg_salary_rounded,  -- rounds to nearest 1000
    MIN(salary) AS min_salary,
    MAX(salary) AS max_salary
FROM employees
GROUP BY department, job_grade
HAVING COUNT(*) >= 5;  -- don't expose groups with fewer than 5 employees

The HAVING COUNT(*) >= 5 clause is deliberate — without it, a determined analyst could infer individual salaries by filtering to groups of one. This is basic statistical disclosure control, and senior candidates who mention it unprompted stand out.

The SECURE keyword on the view hides the view definition from users who don’t own it — they can’t inspect the SQL to reverse-engineer what’s being hidden.

Q13. Walk me through how you’d structure Snowflake RBAC for a mid-sized company — say 3 teams: Data Engineering, Analytics, and Finance BI.

This is an architecture question. A weak answer lists roles. A strong answer describes a hierarchy.

The Snowflake recommendation is a functional role hierarchy:

ACCOUNTADMIN (Snowflake admin only — almost never used day-to-day)
    └── SYSADMIN
            ├── DE_ADMIN (Data Engineering admin role)
            │       ├── DE_DEVELOPER (read/write on raw + staging)
            │       └── DE_READER (read-only on staging)
            ├── ANALYTICS_ADMIN
            │       ├── ANALYTICS_DEVELOPER (read/write on marts)
            │       └── ANALYTICS_READER (read-only on marts)
            └── FINANCE_BI_ADMIN
                    └── FINANCE_BI_READER (read-only on finance mart)

Each human user gets a user role (e.g., user_bug) which is granted the appropriate functional role. Users never log in as SYSADMIN or ACCOUNTADMIN. Those are break-glass roles used only for admin operations, and any use of them should generate an alert via ACCOUNT_USAGE.LOGIN_HISTORY.

Object ownership matters: every object should be owned by a functional role (like DE_ADMIN), not by a personal user account. If the person who created the table leaves, their user is disabled — and if they owned the objects, those objects become inaccessible until ownership is transferred. This is a real operational problem that catches teams who didn’t plan RBAC carefully.

Service accounts (Airflow, dbt, Fivetran) get dedicated roles scoped to exactly what they need. An Airflow service account does not need SYSADMIN. It needs USAGE on specific schemas, CREATE TABLE in specific schemas, and EXECUTE TASK if it manages Tasks. Nothing more.

Category six: Real-World Scenario Questions

These are the ones that show up in final-round interviews and engineering manager panels.

Q14. A finance stakeholder tells you that a revenue number in their Snowflake dashboard changed retroactively — last Tuesday it showed $4.2M, today it shows $3.8M for the same date. How do you investigate and what do you tell the stakeholder?

The first thing I’d do is use Time Travel to find out what the data actually looked like at the time they reported $4.2M:

-- See what the table looked like when they saw 4.2M
SELECT SUM(order_amount) AS total_revenue
FROM orders
  AT (TIMESTAMP => '2024-01-16 09:00:00')  -- time they saw the report
WHERE DATE(order_date) = '2024-01-09';

-- Compare to current value
SELECT SUM(order_amount) AS total_revenue
FROM orders
WHERE DATE(order_date) = '2024-01-09';

If there’s a difference, the data changed between those two timestamps. Now find out what changed:

-- Use a stream-style comparison or Time Travel diff
SELECT order_id, order_amount
FROM orders
  AT (TIMESTAMP => '2024-01-16 09:00:00')

MINUS

SELECT order_id, order_amount
FROM orders;

This gives you the rows that existed in the old version but were removed or changed. Cross-reference these order IDs with the source system — were they returns? Cancelled orders? A pipeline bug that incorrectly deleted records?

What to tell the stakeholder: be transparent and specific. “The revenue figure changed because X orders were retroactively cancelled/corrected in the source system between Tuesday and today. Here are the specific order IDs. The current figure is correct.” Don’t just tell them the number changed — give them the reason and the evidence. Stakeholders who trust your data trust your investigative process.

Q15. You’re designing a Snowflake data platform for a company that has data analysts, data scientists, and BI developers all sharing the same account. Each group runs different query patterns. How do you structure warehouses?

Workload isolation is the core principle. Different query patterns compete for the same resources if they share a warehouse — and they do so invisibly, making debugging harder and degrading everyone’s experience.

My recommended structure:

Analysts warehouse (ANALYTICS_WH — MEDIUM, multi-cluster max 3): Handles ad-hoc analyst queries. These are typically medium-length, moderately complex, need fast turnaround. Multi-cluster handles concurrency spikes when everyone runs queries at once. Auto-suspend after 5 minutes.

BI/Reporting warehouse (BI_WH — SMALL, auto-suspend 1 minute): Serves Tableau/Power BI dashboard queries. These are typically fast, repetitive, and benefit heavily from result cache. Small warehouse is fine because result cache handles most of the work. Short auto-suspend because dashboards tend to query in bursts.

Data Science warehouse (DS_WH — LARGE or XL, auto-suspend 10 minutes): Data scientists run long-running exploratory queries, training feature pipelines, and large aggregations. These need raw compute power. Larger warehouse, longer suspend time to preserve local cache between iterative runs.

Pipeline/ELT warehouse (TRANSFORM_WH — MEDIUM or LARGE, no auto-suspend during pipeline window): Dedicated to dbt, Airflow, and scheduled tasks. Isolated from user-facing workloads so a heavy pipeline run doesn’t slow down analyst queries. Configure Resource Monitor here to prevent runaway pipeline credits.

The key point for interviewers: I explicitly call out that the BI warehouse is small because of result cache behavior. Most candidates say “make BI bigger for performance.” The correct answer is: BI workloads are naturally cache-friendly, so a small warm warehouse outperforms a large cold one for dashboard queries.

Q16. Describe a time Snowflake’s architecture surprised you — either positively or negatively.

I’ll give you a real one from my experience.

I inherited a data pipeline where someone had set up a Snowflake Task tree — about 12 tasks chained together to run a nightly data quality suite. Each task ran a SQL check and wrote results to a DQ log table. The whole tree was supposed to complete in about 25 minutes.

It was taking 3 hours.

When I investigated, I found that the task tree was configured with a 1-minute schedule on the root task but the individual tasks had their dependencies set up as AFTER relationships. What nobody had realized: each task in the chain was waiting for its predecessor to complete AND for the next 1-minute schedule tick before executing. With 12 tasks, each waiting 30-45 seconds plus a 1-minute tick, the chain took enormously longer than expected.

The fix was switching the root task to a scheduled trigger and ensuring the child tasks had AFTER relationships correctly configured as true dependencies (not schedule-based). The tree went from 3 hours to 22 minutes.

What I learned: Snowflake’s Task scheduling documentation is clear, but the interaction between schedule-based and dependency-based triggers is easy to misconfigure in ways that aren’t immediately obvious. Test task trees with short intervals first, watch the execution history, and validate that the AFTER relationships are actually working as dependencies rather than just ordering constraints.

Q17. How would you implement row-level security so that regional sales managers can only see data for their region?

Row-level security in Snowflake is implemented with Row Access Policies.

-- Create a mapping table: which role sees which regions
CREATE OR REPLACE TABLE region_access_map (
    role_name  VARCHAR,
    region     VARCHAR
);

INSERT INTO region_access_map VALUES
    ('SALES_APAC', 'APAC'),
    ('SALES_EMEA', 'EMEA'),
    ('SALES_AMER', 'AMER'),
    ('SALES_ADMIN', 'APAC'),   -- Admin sees everything
    ('SALES_ADMIN', 'EMEA'),
    ('SALES_ADMIN', 'AMER');

-- Create the row access policy
CREATE OR REPLACE ROW ACCESS POLICY region_row_policy
  AS (row_region VARCHAR) RETURNS BOOLEAN ->
    CURRENT_ROLE() = 'SYSADMIN'
    OR EXISTS (
        SELECT 1 FROM region_access_map
        WHERE role_name = CURRENT_ROLE()
          AND region = row_region
    );

-- Apply to the sales table
ALTER TABLE sales_transactions
  ADD ROW ACCESS POLICY region_row_policy
  ON (region);

Now when SALES_APAC queries sales_transactions, Snowflake invisibly adds a filter to every query on that table — they only see APAC rows. They can’t bypass it. They can’t see the policy definition if it’s secured.

Important senior-level detail: Row Access Policies apply at query time, not at storage time. The data is stored together. The filter happens when Snowflake executes the query. This means you can’t accidentally expose data through joins to other tables — the policy applies to the base table regardless of how it’s joined.

One gotcha: if a user’s role changes mid-session, the new policy takes effect on the next query. There’s no session-level snapshot of the policy evaluation.

What Interviewers Are Really Looking For