# Snowflake's FDE interview may start with your future manager

> The job ads make the better study guide: turn a vague business goal into SQL that runs, then into a quality number the customer trusts.

Original: https://fdetimes.net/en/guides/snowflake-fde-interview-guide/

You have just been given an interview slot for a Forward Deployed Engineer role at Snowflake and are about to open LeetCode. Wait. According to Snowflake's careers page, your first conversation may well be with the person who would become your manager. The company describes this as a way to "break the ice" from day one.

To know what to prepare, read the job ad. According to the FDE Applied AI posting, the person in this role spends a lot of time with customers, takes business goals that are not yet clear and turns them into solutions using Python and SQL.

So the best preparation is to practise exactly that chain of work, from the clarifying question to the final quality number.

## What is confirmed, and what is only guesswork

Snowflake's official careers page says the process for technical roles in general has four rounds and can take two to four weeks. Candidates are told to prepare for live coding and assessments with interviewers. At the end come reference checks and a standard background check in line with local employment law.

Snowflake does not publish what each round contains, and the four-round description applies to engineers in general, not to FDEs specifically. Everything else comes from outside sources, so treat it as a hypothesis.

A guide from Aced (formerly Exponent) describes the final stage for software engineers as 3 to 5 panel sessions covering technical skills, domain expertise, system design, behaviour and collaboration.

Candidate reports shared on interviewing.io suggest coding questions are usually at LeetCode medium level, while system design leans towards data systems and database design.

Aced also notes that Snowflake wants to see how you handle large data and work with databases. If your preparation time is limited, put SQL and data design ahead of graph algorithm problems.

## The real problem is the "vague goal"

Snowflake's FDE Applied AI posting asks candidates to turn ambiguous business goals into robust, scalable, high-performance solutions using Python and SQL. The same ad requires at least 25% of time on site with Snowflake's most strategic customers.

It also asks for experience building LLM applications, particularly RAG and agentic workflows. You must have defined quality metrics and run evals for LLM or agent systems yourself.

The staff-level posting is more explicit still: translate ambiguous customer goals into measurable metrics, eval frameworks and golden datasets.

**Key point:** Preparing for an FDE interview means practising how to turn a vague request into a measurable number.

## A sample exercise: "reduce the load on the support team"

Picture this problem: the customer is a retailer that stores support tickets in Snowflake and wants an AI assistant to "reduce the load on the support team". If you rush to sketch a RAG architecture, you have skipped the most important step.

Ask first: how is reducing the load measured, response time or the number of tickets humans have to handle? Which ticket category is the largest? Which tables hold the data?

Suppose the interviewer answers: it is measured by first response time, and the data sits in two tables, `tickets` and `messages`. The first job is to get a baseline, because without one you cannot prove any value. The SQL below runs on Snowflake:

```sql
-- First response time by category, last 90 days
WITH first_reply AS (
  SELECT ticket_id, MIN(sent_at) AS first_agent_reply_at
  FROM messages
  WHERE sender_type = 'agent'
  GROUP BY ticket_id
)
SELECT t.category,
       COUNT(*) AS tickets,
       COUNT(f.ticket_id) AS replied_tickets,
       MEDIAN(DATEDIFF('minute', t.created_at, f.first_agent_reply_at)) AS median_first_reply_min
FROM tickets t
LEFT JOIN first_reply f ON f.ticket_id = t.ticket_id
WHERE t.created_at >= DATEADD('day', -90, CURRENT_DATE)
GROUP BY t.category
ORDER BY tickets DESC;
```

The point worth making is the `first_reply` CTE. If you join `tickets` directly to `messages`, a ticket with six messages becomes six rows, and `COUNT(*)` counts messages rather than tickets. Get into the habit of collapsing each ticket to one row before the join, and say why as you write it.

The `LEFT JOIN` is deliberate too. It keeps tickets nobody has answered yet, and the `replied_tickets` column shows how many there are. Say out loud that the median covers only tickets that have had a reply, so the unanswered group must be reported separately.

## What is the 80% hiding?

Now the eval. Suppose you build a golden dataset of 50 questions taken from real tickets: 30 about billing and 20 about technical faults. The agent gets 40 right, or 80%. That sounds fine until you split it by category: billing scores 29/30, while technical gets only 11/20, or 55%.

```python
from collections import defaultdict

def score_by_category(results):
    totals, correct = defaultdict(int), defaultdict(int)
    for r in results:
        totals[r["category"]] += 1
        correct[r["category"]] += int(r["is_correct"])
    return {c: correct[c] / totals[c] for c in totals}
```

Now connect this back to the original SQL. If the baseline shows technical tickets are the largest category, the 80% is hiding exactly the area the customer needs most. A sensible recommendation would be: "Roll out to the billing category first; the technical category needs more documentation for retrieval, then a fresh evaluation."

The staff-level posting lists eval and observability tools such as Braintrust, LangSmith, Arize, Weave and Promptfoo among its preferred skills. Knowing one of them is an advantage. But if you can explain why scores must be split by category, any tool is just a detail.

## The content of each round is not public. How should you prepare?

Since Snowflake does not say which round tests what, prepare around what is confirmed and what the job ads require. Start with live coding: practise LeetCode medium problems in Python, talking aloud as you work. In parallel, revise SQL the way data people use it: window functions, CTEs, `LEFT JOIN` with NULL values, and row duplication when joining one-to-many relationships.

For system design, practise designing data systems rather than social networks or ride-hailing apps. A good problem to practise on your own: load new tickets into a table, update the RAG index, and store eval results for each prompt version. Draw the schema, identify the primary keys, and explain how you would query the eval table to compare two versions.

For the hiring manager and the behavioural sessions, prepare two stories: one about a time you turned a vague request into a metric, and one about working directly with users or customers. Because there are reference checks, warn your referees in advance so they describe the same projects you mention.

On your CV, do not write a generic "experience with LLMs". Write a line that can be checked, such as "built a 50-question golden dataset, split scores by category, found the technical category scored only 55%". This advice holds for any FDE role, not just Snowflake.

## The mistakes that sink strong candidates

The most common mistake is solving the problem before asking how the goal is measured. In a role whose job ad uses the word "ambiguous" explicitly, skipping the clarifying step means skipping the very skill the ad emphasises.

Next is writing SQL that produces a number without checking whether the number is plausible. Simply counting tickets before and after the join is enough to catch row duplication. Nor should you report a single overall eval score and stop there, when the customer needs to know where the agent fails.

The last mistake is one few people notice: treating the hiring manager meeting as a mere introduction. Snowflake calls it an icebreaker, but for a role that spends at least 25% of its time with customers, use that session to show how you communicate and ask questions.

If you can do only one thing this week, work through the full "reduce the load on the support team" exercise on a real dataset, from clarifying questions to the per-category scorecard. Once you can run that chain smoothly, you will have something to say in every round.

**Try this week:**

- Take a public ticket dataset, write SQL that calculates first response time by category, then check for yourself whether the join duplicates rows.
- Build a 50-question golden dataset for a small RAG application, score it by category and write five lines explaining which category is weakest.
- Prepare a three-minute story about a time you turned a vague request into a measurable metric, to tell the hiring manager in the very first round.

## Sources

- [Hiring Process | Snowflake Careers](https://careers.snowflake.com/us/en/gethired)

- [Forward Deployed Engineer, Applied AI (Snowflake)](https://careers.wing.vc/companies/snowflake/jobs/65567988-forward-deployed-engineer-applied-ai)

- [Staff Applied AI Engineer (FDE)](https://careers.wing.vc/companies/snowflake/jobs/80168696-senior-forward-deployed-engineer-applied-ai)

- [Get a Job at Snowflake: Interview Process and Top Questions (Aced, formerly Exponent)](https://www.aced.io/blog/snowflake-interview-process)

- [Snowflake Interview Process & Questions in 2024 (interviewing.io)](https://interviewing.io/snowflake-interview-questions)