In this post we are going to cover real-world manager scenarios in Snowflake: a slow CFO dashboard, a migration from SQL Server or Teradata, dev, test and prod with Git, Snowpark, wrong totals, an inherited account and a full platform design. These are 7 real Snowflake interview questions, asked the way they come up on a real project, and the last one is a scenario where the hiring manager asks you to design a Snowflake data platform for a retail company from scratch.
This is the last part of the series, and it is different from the others. There is no single feature to explain. The manager wants to hear your order of steps: what you do first, what you check, and what you tell the business. Interviewers ask these in the final round because they show whether you have actually run Snowflake in a real company.
Part 10 of the Real Time Snowflake Interview Questions and Answers series on TechBrothersIT.
- The short answer
- Question 1: The CFO's dashboard is slow every Monday morning. Walk me through your response.
- Question 2: Leadership asks whether to move from SQL Server or Teradata to Snowflake. How do you assess it, and what is your migration plan?
- Question 3: Three developers change the same objects in production by hand. How do you set up dev, test and prod with Git and CI/CD?
- Question 4: The data science team wants to run Python next to the data. When do you use Snowpark, and how does it run?
- Question 5: A pipeline succeeded but the report shows wrong totals. How do you trace the problem from report back to source?
- Question 6: You inherit a Snowflake account with no standards and a growing bill. What do you put in place first?
- Scenario 7: In the final round, the hiring manager asks you to design a Snowflake data platform for a retail company from scratch. What is your design?
The short answer
In an incident, communicate first, then read query history: queuing or slow running. Migrate in phases with a parallel run, keep every object in Git and deploy with a pipeline, and use Snowpark when Python is the right tool. Trace wrong totals layer by layer with Time Travel, put guardrails on an inherited account first, and design platforms that are governed and safe to rerun.
Keep that in mind. Every question below is one piece of it.
Question 1: The CFO's dashboard is slow every Monday morning. Walk me through your response.
Communicate first, then get the facts from query history. The CFO's team should hear from you before they start guessing.
So first, tell them you're on it. Then open query history for Monday morning and ask one question: is the time spent queuing, or running? Query history separates queued time from execution time.
If it's queuing, everyone opens dashboards at once on one warehouse. Use a multi-cluster warehouse, which needs Enterprise edition, with the standard scaling policy, or give the CFO's dashboards their own warehouse. Resizing helps slow queries, not concurrency.
If it's running slow, open the Query Profile. Look for spilling to remote storage, poor pruning where partitions scanned is close to the total, or an exploding join. Query insights flag many of these for you.
Here is what each finding means and how to fix it:
| In query history | Cause | Fix |
|---|---|---|
| HIGH QUEUED TIME | too many queries at once | multi-cluster, or its own warehouse |
| REMOTE SPILLING | not enough memory | bigger size, smaller batches |
| SCANNED CLOSE TO TOTAL | poor pruning | selective filter, clustering key |
| ONLY ON MONDAY | weekend loads: cold caches | loads finish early, warm cache |
Then ask why Monday. Weekend loads changed the tables, so the result cache can't be reused, and the suspended warehouse lost its local cache. Sometimes a weekend batch is still running on the same warehouse.
Separate load and BI warehouses, make loads finish early, and give the BI warehouse at least 10 minutes of auto-suspend to keep its cache warm.
Question 2: Leadership asks whether to move from SQL Server or Teradata to Snowflake. How do you assess it, and what is your migration plan?
Assess before you promise. Inventory databases, ETL jobs, stored procedures and reports. Then name the pain, like concurrency limits or long batch windows. Separate storage and compute help, but they won't fix a bad data model.
Next, pick the edition early:
- Enterprise - masking, row access, multi-cluster warehouses and 90-day Time Travel.
- Business Critical - private connectivity and regulated data like HIPAA or PCI.
Then convert. Let's look at how each piece maps:
| On SQL Server or Teradata | On Snowflake | Watch for |
|---|---|---|
| TABLES AND VIEWS | tables and views | data type checks |
| STORED PROCEDURES | Snowflake procedures or dbt models | SnowConvert AI, then review |
| INDEXES, STATISTICS | micro-partition pruning | clustering key only if needed |
Tables and views mostly map, with data type checks. Snowflake's SnowConvert AI tool automates much of the SQL translation, but stored procedures still need review or a rewrite, as Snowflake procedures or dbt models. Indexes don't carry over: Snowflake prunes with micro-partition metadata, plus a clustering key where needed.
For history, export compressed files of about 100 to 250 MB to cloud storage and load them with COPY INTO. Then incremental loads keep new data flowing while both systems run.
The plan is phased, not big bang:
- Pilot - one subject area, end to end.
- Parallel run - run it next to the old system, and reconcile row counts and totals every day.
- Move the next area - one by one.
- Cut over - switch the old system off last.
Leadership sees matching numbers before anything is switched off. That is a much easier conversation than a big bang date.
Question 3: Three developers change the same objects in production by hand. How do you set up dev, test and prod with Git and CI/CD?
The root problem is that production, not Git, is the source of truth. So every object definition lives in Git, and no personal login can change production. Only the deployment pipeline's service user can.
Let's set it up step by step:
- Dev - a zero-copy clone of production, and each developer works on a feature branch.
- Pull request - reviewed and merged into main.
- Test - the pipeline deploys and runs checks.
- Prod - after approval, the same code is deployed, by the service user only.
-- dev: zero-copy clone of production
CREATE DATABASE sales_dev CLONE sales_prod;
-- the same file is deployed to test, then prod
CREATE OR ALTER TABLE sales.orders (
order_id NUMBER,
amount NUMBER(12,2),
region STRING
);The clone is quick, and you pay storage only for changes. But cloned tasks start suspended, and a cloned pipe can still load into production if it uses a fully qualified table name. So check cloned pipes.
Then pick one deploy tool per object:
| Tool | Use it for |
|---|---|
| DCM PROJECTS | desired state, plan, deploy |
| CREATE OR ALTER | many object types |
| DBT PROJECTS | transformations |
| SCHEMACHANGE | community, versioned |
DCM Projects are generally available: define the desired state, plan, then deploy. CREATE OR ALTER is generally available for many object types, dbt Projects run transformations, and schemachange is a community option.
The pipeline runs the Snowflake CLI, whose GitHub Action is generally available, and signs in with workload identity federation. No password or key is stored.
Question 4: The data science team wants to run Python next to the data. When do you use Snowpark, and how does it run?
Snowpark lets you write DataFrame code in Python and turns it into SQL that runs on a Snowflake warehouse. The data never leaves Snowflake, so nothing is exported to a laptop or a separate cluster.
DataFrames are lazy. Filter, group by and aggregate only build the query. Nothing runs until an action, like collect, show, count, or save as table. Here we total positive orders by region and save the result:
from snowflake.snowpark.functions import col, sum as sum_
# nothing runs yet: this only builds the query
df = (session.table("raw.orders")
.filter(col("amount") > 0)
.group_by("region")
.agg(sum_("amount").alias("total_amount")))
# the action: SQL runs on the warehouse
df.write.mode("overwrite").save_as_table(
"gold.sales_by_region")The save_as_table call is the action, and that is when the SQL runs on the warehouse.
For logic SQL can't express, you push Python into Snowflake:
| Python inside Snowflake | Use it for |
|---|---|
| UDF | row-by-row logic |
| VECTORIZED UDF | batches with pandas |
| UDTF | table functions |
| STORED PROCEDURE | whole workflows, model training |
Then compute. For memory-heavy work, like training a model in a stored procedure, use a Snowpark-optimized warehouse, with 16 times the memory per node by default. Plain DataFrame work is fine on a standard warehouse.
For exploration, the team uses Snowflake Notebooks in Workspaces, on the container runtime with PyPI packages.
Use Snowpark when the team needs Python. For plain SQL, keep it SQL.
Question 5: A pipeline succeeded but the report shows wrong totals. How do you trace the problem from report back to source?
Succeeded only means every step ran without an error. It says nothing about the data. So I walk backwards one layer at a time and compare one number, like yesterday's sales total, at each step.
The path is source, raw, silver, gold, then the report. We go from the right to the left:
- Report - a changed filter, a join to a dimension with duplicate keys, or a cached extract.
- Gold - compare totals by day.
- Silver - if gold is off, check for duplicate business keys.
- Raw - compare row counts with the source.
In Snowflake, the classic causes are known:
- MERGE - inserts duplicates silently when duplicate source keys are new to the target.
- COPY with FORCE - a rerun with force reloads files.
- Recreated pipe - it loses its load history, so old files can load again.
Then Time Travel shows the table before the bad load:
-- silver: duplicate business keys
SELECT order_id, COUNT(*) AS copies FROM silver.orders
GROUP BY order_id HAVING COUNT(*) > 1;
-- gold total before the bad load
SELECT SUM(amount) AS total FROM gold.fact_sales
BEFORE (STATEMENT =>
'01b8f6a2-0002-4a1c-0000-00012f2e3d51');
-- restore from that point
CREATE TABLE gold.fact_sales_restored
CLONE gold.fact_sales BEFORE (STATEMENT =>
'01b8f6a2-0002-4a1c-0000-00012f2e3d51');The first query finds duplicate order ids in silver. The second gives the gold total before the load's statement ID, so we can compare. And if needed, the clone restores the table from that point.
Check row counts, totals against the source, and duplicate business keys after each load. If a check fails, fail the pipeline before the report refreshes.
Question 6: You inherit a Snowflake account with no standards and a growing bill. What do you put in place first?
Don't start by deleting things. Start with the bill, then guardrails, then access, then standards.
Here is the order, step by step:
- Inventory and the bill - warehouse metering history shows credits per warehouse, query attribution history shows credits per query, and cost management in Snowsight shows the trend.
- Cost guardrails - every warehouse gets auto-suspend and auto-resume. Lower the statement timeout from its two-day default, so one bad query can't run all weekend.
- Access - this is the real risk. Check who has ACCOUNTADMIN, move every human user to MFA, and let only a few people create or resize warehouses. Build read, write and admin roles per database, granted up to SYSADMIN.
- Standards - a naming convention, one warehouse per workload, tags for team and cost center so budgets and chargeback work, and transient tables for staging data you can rebuild.
- Change control - new objects only through Git and a pipeline, and a monthly review of cost anomalies and the top queries.
Here is the first week in SQL:
SELECT warehouse_name, SUM(credits_used) AS credits
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time > DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY warehouse_name ORDER BY credits DESC;
ALTER WAREHOUSE bi_wh SET AUTO_SUSPEND = 600
STATEMENT_TIMEOUT_IN_SECONDS = 3600;The first query ranks warehouses by credits over the last 30 days. The second sets auto-suspend and a one-hour statement timeout on the BI warehouse.
Then add resource monitors, and a budget that also covers serverless features:
| Guardrail | Covers |
|---|---|
| RESOURCE MONITOR | warehouses only |
| BUDGET | warehouses and serverless |
| TIMEOUT | runaway queries |
Retire unused objects only after their owners agree.
Scenario 7: In the final round, the hiring manager asks you to design a Snowflake data platform for a retail company from scratch. What is your design?
Let's build it from the sources to the dashboards, then add what goes around it.
- Sources. Store sales, e-commerce and ERP data land as files in cloud storage, and Snowpipe with auto-ingest loads them within minutes. Click events come through the Kafka connector on Snowpipe Streaming, in seconds.
- Storage. Three layers: raw as it arrived, with JSON in VARIANT columns; silver cleaned and merged by business key; and gold as a star schema.
- Transform. Dynamic tables with a target lag refresh the layers, and streams and tasks handle SCD Type 2 merges.
- Compute. One warehouse per workload: loading, transformation, a multi-cluster warehouse for BI, and one for data science. Each auto-suspends, and budgets and resource monitors track the credits.
Then everything around it:
- Security. A role hierarchy, MFA for people and key pairs for services, masking through tags, and row access so store managers see only their region. Suppliers get a secure share of their own sales.
- Operations. Every object in Git, deployed by a pipeline, loads that are safe to rerun, Time Travel for mistakes, and a failover group to a second region on Business Critical.
Every piece is governed, every load is checked, and every step is safe to rerun. That is a platform the business can trust.
That is the end of the series. If you worked through all 10 parts, you have the answers for the questions that actually come up on Snowflake projects, from warehouses to this final design.
Key points to remember
- Slow Monday: communicate, then queued or slow in query history
- Migration: inventory, edition, convert, migrate in phases
- Every object in Git; deploy with a pipeline and a service user
- Snowpark runs Python as SQL on the warehouse; data stays put
- Wrong totals: trace layer by layer; guardrails before cleanup
All 10 parts are listed on the Real Time Snowflake Interview Questions and Answers page on this blog.
Part of the Real Time Snowflake Interview Questions and Answers series on TechBrothersIT. Features, limits and their status (GA or preview) are current as of October 2026; check the Snowflake documentation for anything you quote in an interview.