A few years ago, a good Snowflake developer was mostly a strong SQL developer who knew how warehouses and credits behaved. The platform has since grown well past that. Dynamic tables have taken over a lot of hand-built pipeline logic, Iceberg tables have opened the account up to other engines, Python runs inside the platform through Snowpark, and Cortex AI features put models next to the data. Teams also have to answer for serverless costs that never appear on a warehouse dashboard. Snowflake developer skills now stretch from reading a query plan to explaining a bill to finance.
This post covers eight technical skills with a check for each one, the habits that make someone useful on a shared platform, what has gained and lost weight, a matrix by level and an assessment process.
Core technical skills for a Snowflake developer
Pruning and micro-partition thinking
Snowflake has no conventional indexes for ordinary tables, so speed depends on how well a query skips micro-partitions. Good developers write filters the optimiser can use, and they know how load order affects natural clustering. How to check it: show a query that filters on a date column wrapped in a formatting function, and a Query Profile showing nearly every partition scanned. Ask why it reads so much and how they would rewrite it. A strong candidate moves the function off the column and checks partitions scanned afterwards.
Semi-structured data
Many sources now arrive as JSON, and VARIANT columns make it simple to load without deciding much. The skill lies in what happens next: flattening nested arrays, coping with fields that change type and promoting heavily used values into proper columns. How to check it: give a nested order document with an array of line items, where the price arrives as a number in some rows and a string in others. Ask for a clean table of order lines, and what they would do when a new field appears. Watch for careful casting and a plan for rows that fail.
Change tracking with streams
Streams look simple until something goes wrong. A stream records an offset, and consuming it inside a transaction moves that offset forward. It can also go stale if it is left unread for too long. How to check it: ask whether two downstream tasks can safely share one stream on the same table. Good candidates explain that the first consumer advances the offset, so the second would miss changes, and each needs its own stream. Then ask how they would notice a stream drifting towards staleness before it fails.
Recovery and safe testing with Time Travel and clones
Time Travel lets a developer query or restore earlier data within a retention period, and zero-copy clones give a full-looking copy without duplicating storage at first. Together they change how teams test and recover. How to check it: say a bad MERGE corrupted a large table yesterday afternoon, and ask how they would restore it and find what was affected. Follow up by asking how Fail-safe differs from Time Travel. Candidates should know Fail-safe requires Snowflake support, and that transient tables do not have it.
Role design that survives deployments
Role hierarchies are easy to draw and harder to keep working. Objects replaced during a deployment can lose their grants, and teams then patch access by hand. Strong developers use future grants, managed access schemas and service accounts that sign in with key pairs or OAuth, since Snowflake’s phased rollout has been blocking password-only sign-in on most accounts, service users included. How to check it: say analysts lose access to a table after every dbt run. Ask why this happens and how they would fix it permanently. Look for an understanding of CREATE OR REPLACE, COPY GRANTS and future grants.
Snowpark and Python inside the platform
Snowpark runs DataFrame code inside Snowflake, so work stays where the data is. Its API feels familiar to anyone who knows Spark, which helps on migrations from Spark jobs. The common mistake is pulling data out to process it. How to check it: show code that calls to_pandas on a large table, filters it in memory and writes it back. Ask what is wrong and what they would do instead. A strong candidate pushes the filter into the query, and can explain when a stored procedure or plain SQL is the better home for the logic.
Cost attribution
Finding a wasteful warehouse is the start. The harder task is telling each team what it spends, including work that runs outside warehouses. Good developers use query tags and object tags, and they know serverless features carry their own charges. How to check it: say finance wants credits split by department, and three departments share one warehouse. Ask how they would do it, then ask which kinds of spend a resource monitor will not stop. Good answers mention tagging or query-level attribution, and that resource monitors apply to warehouses, not serverless features.
Migration from older warehouses
Moving from Teradata, Oracle or Hadoop is a typical brief, and most of the risk sits outside the table definitions: stored procedures, BTEQ scripts, scheduler logic and habits built around indexes. How to check it: describe a Teradata job that relies on volatile tables and a BTEQ wrapper. Ask what will not carry over directly, and how they would prove that the numbers match after cutover. Good candidates plan a parallel run and reconcile on row counts and aggregates by business key, and they accept that some code should be redesigned instead of translated.
Working skills that separate good from average
- Explaining credits to people who do not care about credits. Strong developers translate warehouse settings into what a department pays and what it gets, which makes it easier to win support for a cost change.
- Protecting a shared account. Every team wants its own warehouse and a little more access. Good developers set patterns that say no politely, and document why, so one request does not become the precedent for many.
- Working closely with BI teams. Dashboards drive a large share of queries. Developers who sit down with report builders can fix a model once instead of tuning queries forever.
- Following platform releases. Snowflake ships changes often, including behaviour changes that can affect existing code. Careful developers read the notes and test in advance.
Skills gaining and losing ground in 2026
Mattering more. Open table formats matter more now that companies want one copy of data readable by several engines, so knowing when Iceberg tables make sense is a real advantage. Cortex AI features have added work on preparing documents and on describing data well enough for natural-language querying, which depends on clean models and good naming. Reviewing generated SQL is a daily need, because an assistant can write a correct query that burns credits through a needless cross join. Deployment through Git, CI and Terraform or schemachange is now the norm for serious accounts.
Mattering less. Hand-built chains of tasks are often unnecessary where a dynamic table can declare the result and a target lag. Traditional tuning knowledge such as index design carries over poorly, and vacuuming simply does not arise here. Clustering every large table by default was never wise and is less common now that teams measure it.
Snowflake developer skills matrix by level
| Skill area | Junior | Mid-level | Senior |
|---|---|---|---|
| SQL and pruning | Writes clean, correct queries | Reads Query Profile and fixes scans | Sets query and clustering standards |
| Semi-structured data | Queries VARIANT and flattens arrays | Handles type drift and new fields | Decides what gets modelled and when |
| Pipelines | Extends existing tasks and dbt models | Owns streams, tasks and dynamic tables | Designs loading patterns for the account |
| Recovery and testing | Knows Time Travel basics | Uses clones for safe testing | Sets retention and recovery policy |
| Access | Works within assigned roles | Builds grants and masking policies | Designs the role hierarchy and service access |
| Cost | Understands credits and auto-suspend | Answers for own workload spend | Runs attribution and budgets across teams |
| Migration | Converts and tests single objects | Migrates subject areas with reconciliation | Plans the sequence and the cutover |
How to assess Snowflake skills in a hiring process
Snowflake on a CV can mean anything from querying through a BI tool to running the account. Start from a clear Snowflake developer job description, then use these steps to find out which one you are looking at.
- Design a warehouse layout on paper. Describe overnight loads, a busy BI tool and a data science team, then ask how they would divide compute, set suspension and report spend. The reasoning matters more than the sizes chosen.
- Walk through an incident. Ask them to describe a failure they handled on a live account, such as a stale stream or a load that silently skipped files. Details such as COPY history or task history show who was really there.
- Ask for a reconciliation record. For migration roles, ask what proved that the new platform matched the old one, and who signed that off.
Red flags on a CV: daily use of ACCOUNTADMIN described as a strength; “Snowflake tuning” that talks about indexes; a SnowPro badge with no production account behind it; “real time” claimed for hourly tasks; and no mention of warehouses, roles or cost anywhere in the work history.
Frequently asked questions
Can an Oracle or Teradata developer pick up Snowflake?
Yes, and their SQL and warehouse knowledge is valuable. The adjustment is letting go of indexes and physical tuning, and starting to think about credits.
Do Snowflake developers need Python?
Not always. Many roles are mainly SQL and dbt. Python becomes important where Snowpark, custom ingestion or machine learning work is involved, so decide whether the job needs it instead of asking by default.
Should a Snowflake developer know dbt?
It is widely used alongside Snowflake and is worth asking for if you run it. Someone who knows SQL deeply can learn the tool quickly. What you want to see is the habit behind it: tested, documented, version-controlled models, whatever the tooling.
How much cloud knowledge does a Snowflake developer need?
Enough to connect the platform to the rest of your estate. That means storage integrations, event notifications for Snowpipe, identity and network policies on AWS, Azure or Google Cloud. Deep infrastructure skills usually sit with a cloud or platform engineer.
Teams planning a build, a migration or a cost clean-up can talk to Zilo AI. Shortlists follow the services you actually run, screening covers SQL, Spark and cost awareness, and you can hire Snowflake developers in India on contract, contract-to-hire or permanent terms, or browse wider IT talent for the rest of the data team. Reach out with your cloud, your sources and what the platform needs to do next.