SQL for FDE Interviews: The Queries You Will Write on Messy Customer Data
Key Insights
- FDE SQL interviews test data reasoning, not just syntax. You need to understand unfamiliar schemas, table grain and messy customer data before writing the query.
- Real customer data rarely behaves like a clean interview dataset. Duplicates, NULLs, missing relationships and inconsistent records can change how a query should be written.
- Joins and window functions solve many practical FDE problems. LEFT JOIN, ROW_NUMBER(), RANK() and related patterns help handle missing relationships, latest records and customer-level analysis.
- The same business question can require different SQL approaches. Finding a failed payment is different from finding a customer’s latest failed payment, making query logic and ordering important.
- Query validation is part of solving the problem. Check table grain, row counts, duplicate records and edge cases to make sure the result actually answers the business question.
- The best preparation is practice with messy customer data. Focus on explaining the path from business problem to data required, query logic, edge cases and final result.
For Forward Deployed Engineer (FDE) interviews at top tech companies like Palantir, OpenAI, and Anthropic, SQL is a core technical requirement. However, FDE interviews differ significantly from standard data analyst or software engineering interviews. Interviewers are not just testing whether you know isolated SQL syntax; they test how well you work with real customer data, where duplicate records, missing values, inconsistent timestamps and multiple tables can make a simple business question harder to answer.
This guide covers the most common SQL interview questions with solutions for FDE, explains what each problem is testing, and shows how to approach these queries using realistic customer-data examples.
Why does SQL Show Up in FDE Interviews?
An FDE may work directly with customer data while investigating a problem, validating an integration or preparing data for an AI application. Unlike a clean textbook dataset, this data can contain duplicates, missing values, inconsistent timestamps and incomplete transaction histories, often spread across several tables. SQL helps FDEs make sense of this data and turn a business problem into a reliable answer.
FDEs Work With Customer Data, Not Just Clean Datasets
Imagine a customer appearing three times in a database because different systems created separate records. Their email may be the same, their names may differ slightly and one record may have a missing country. An order table may contain several purchases for that customer, while an events table records their product activity and a payment table contains both successful and failed attempts.
The SQL query has to account for these relationships. It is not enough to know how to write a JOIN. You also need to understand which table contains the required information, what each row represents, how many rows belong to one customer and what should happen when a matching record does not exist.
SQL Tests Practical Data Reasoning
This is why SQL can be useful in FDE interview questions. An interviewer can give you an unfamiliar schema and ask you to turn a business problem into a query, rather than simply asking you to recall a particular SQL function.
The question may look simple on the surface, but you still need to determine the correct table grain, join related datasets without multiplying rows, aggregate at the right level and handle edge cases such as NULL values or missing relationships. The interview is therefore testing more than SQL syntax. It is testing whether you can reason about messy customer data and translate that reasoning into a reliable query.
12 SQL Interview Questions You Should Practise With Messy Customer Data
The best way to prepare for SQL problems for FDE interviews is to practise realistic customer-data problems involving joins, deduplication, NULLs, window functions, date logic and data quality. We’ll use the same fictional database throughout so you can focus on the reasoning behind each query. The examples use PostgreSQL syntax.
| Table | Purpose |
| customers | For customer details |
| orders | For customer orders |
| payments | For payment records |
| events | For customer activity |
These are fictional table names created for the examples, with fields such as customer_id, order_date, payment_date and event_at. For each question, focus on understanding the problem, choosing the right SQL approach and checking the result for edge cases.
1. Find Customers Who Have Placed at Least One Order
An interviewer may ask: “Find all customers who have placed at least one order.” This looks like a basic join, but there is an important detail. A customer can have multiple orders, so the query should return each customer only once.
SELECT DISTINCT c.customer_id, c.name, c.email
FROM customers c
JOIN orders o
ON c.customer_id = o.customer_id;The JOIN connects the two tables through customer_id, while DISTINCT prevents a customer with several orders from appearing several times. This tests whether you understand both SQL joins and the difference between order-level and customer-level results.
2. Find Customers With No Orders
A common SQL interview question is: “Find all customers who have never placed an order.” Here, the missing relationship is the important part.
SELECT c.customer_id, c.name
FROM customers c
LEFT JOIN orders o
ON c.customer_id = o.customer_id
WHERE o.order_id IS NULL;The LEFT JOIN keeps every customer, including those without a matching order. The NULL condition then identifies the customers on the unmatched side. An INNER JOIN would remove those customers before the filter is applied, so it would not answer the question correctly.
3. Remove Duplicate Customer Records
Suppose the same email appears across several customer records and the business wants to retain the most recently updated record. This is a typical SQL deduplication interview question.
WITH ranked AS (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY email
ORDER BY updated_at DESC
) AS rn
FROM customers
)
SELECT *
FROM ranked
WHERE rn = 1;ROW_NUMBER() assigns a position to each record within the same email group. The most recently updated record receives 1. This is different from using DISTINCT, which can remove identical rows but cannot decide which version of two conflicting records should be retained.
The business rule matters here. An interviewer may change the requirement and ask you to keep the oldest record, the record with a verified email or the record with the most complete information.
4. Find the Latest Order for Each Customer
The interviewer may ask: “Return the latest order for every customer, including all the details of that order.”
SELECT *
FROM (
SELECT o.*,
ROW_NUMBER() OVER (
PARTITION BY customer_id
ORDER BY order_date DESC
) AS rn
FROM orders o
) x
WHERE rn = 1;This is where window functions become useful. MAX(order_date) can tell you the latest order date, but it does not automatically give you the other columns from that same row. ROW_NUMBER() lets you select the complete latest record.
5. Find Customers With Multiple Orders on the Same Day
An interviewer could ask: “Which customers placed more than one order on the same day?” The key is to group at the correct level.
SELECT customer_id,
order_date::date AS order_day,
COUNT(*) AS order_count
FROM orders
GROUP BY customer_id, order_date::date
HAVING COUNT(*) > 1;The query groups orders by both customer and date, then uses HAVING to keep groups with more than one order. This tests aggregation and date handling at the same time. If you grouped only by customer, you would lose the information about when the orders happened.
6. Calculate Monthly Revenue From Customer Orders
A practical SQL customer data query for engineers could be: “Calculate total customer revenue for each month.” This requires date bucketing followed by aggregation.
SELECT DATE_TRUNC('month', order_date) AS month,
SUM(total_amount) AS revenue
FROM orders
GROUP BY 1
ORDER BY 1;DATE_TRUNC() converts each order date into its corresponding month, while SUM() calculates revenue for that month. This example uses PostgreSQL. Date functions vary across SQL dialects, so you should clarify whether the interview expects PostgreSQL, MySQL, SQL Server or another database before relying on dialect-specific syntax.
7. Find the Top 3 Customers by Revenue in Each Month
A more involved question might ask: “For every month, find the three customers who generated the most revenue.” This requires two separate steps: first calculate monthly revenue per customer, then rank those customers within each month.
WITH monthly AS (
SELECT DATE_TRUNC('month', order_date) AS month,
customer_id,
SUM(total_amount) AS revenue
FROM orders
GROUP BY 1, 2
),
ranked AS (
SELECT *,
RANK() OVER (
PARTITION BY month
ORDER BY revenue DESC
) AS rnk
FROM monthly
)
SELECT *
FROM ranked
WHERE rnk <= 3;The first CTE produces one row per customer per month. The second applies RANK() separately within each month. Notice that RANK() can return more than three rows if there is a tie. If the requirement is exactly three rows per month, ROW_NUMBER() may be more appropriate.
8. Handle NULL Values in Customer Data
One may get a customer table where some countries are missing and ask us to display “Unknown” instead.
SELECT customer_id,
COALESCE(country, 'Unknown') AS country
FROM customers;COALESCE() returns the first non-NULL value, so missing countries are replaced with “Unknown”. You should also know that NULL is not an ordinary value. A condition such as country = NULL does not correctly identify missing values. Use IS NULL or IS NOT NULL instead.
9. Find Customers Whose Latest Payment Failed
Consider a customer who has had several payment attempts. A question such as “Find customers whose latest payment failed” is different from asking whether they have ever had a failed payment.
WITH latest AS (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY customer_id
ORDER BY payment_date DESC
) AS rn
FROM payments
)
SELECT customer_id, payment_id, payment_date
FROM latest
WHERE rn = 1
AND status = 'failed';The query first identifies the latest payment for every customer. Only after that does it check the payment status. Simply filtering status = ‘failed’ would incorrectly include customers whose latest payment succeeded but who had a failed payment in the past.
10. Identify Customers With No Activity in the Last 30 Days
An interviewer may ask: “Find customers who have not been active in the last 30 days.” The query also needs to account for customers who have never recorded an event.
WITH activity AS (
SELECT customer_id,
MAX(event_at) AS last_activity
FROM events
GROUP BY customer_id
)
SELECT c.customer_id,
c.name,
a.last_activity
FROM customers c
LEFT JOIN activity a
ON c.customer_id = a.customer_id
WHERE a.last_activity IS NULL
OR a.last_activity < CURRENT_TIMESTAMP - INTERVAL '30 days';There are two cases here. A customer may have activity, but their latest activity may be more than 30 days old. Or they may have no activity at all. Treating those as separate cases prevents an important edge case from being missed.
11. Find the First and Most Recent Event for Each Customer
A question might ask: “Find the first and most recent event for every customer, including the event type.” MIN() and MAX() can find the dates, but they do not reliably return the other columns belonging to those records.
WITH ranked AS (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY customer_id
ORDER BY event_at
) AS first_rn,
ROW_NUMBER() OVER (
PARTITION BY customer_id
ORDER BY event_at DESC
) AS latest_rn
FROM events
)
SELECT customer_id,
MAX(event_at) FILTER (WHERE first_rn = 1) AS first_event,
MAX(event_type) FILTER (WHERE first_rn = 1) AS first_event_type,
MAX(event_at) FILTER (WHERE latest_rn = 1) AS latest_event,
MAX(event_type) FILTER (WHERE latest_rn = 1) AS latest_event_type
FROM ranked
GROUP BY customer_id;The important reasoning is that the first and latest events are rows, not just dates. Window functions let you identify those rows before selecting the associated event types.
12. Detect Customers With Conflicting or Inconsistent Data
Messy customer data can contain contradictions. An interviewer might ask: “Find email addresses that are associated with more than one customer name.”
SELECT email,
COUNT(DISTINCT name) AS name_count
FROM customers
GROUP BY email
HAVING COUNT(DISTINCT name) > 1;The same pattern can be used to identify a customer ID associated with multiple countries or other conflicting attributes. This is a practical data-quality problem because the query is being used to discover an issue in the underlying customer data.
How to Approach SQL Questions in an FDE Interview?
The strongest candidates do not immediately start typing SQL. They first make sure they understand the business question and the data.
Start With the Business Question
Before writing the query, identify what the result should represent and which tables contain the required information. Pay attention to table grain: if the question asks for one row per customer but you start from an order-level table, a join can easily produce multiple rows per customer.
Inspect the Data Before Writing the Query
Think through the primary and foreign-key relationships, NULL values, duplicate records, date formats and unexpected values. Most importantly, check whether a join could multiply rows. Joining one customer to five orders may be correct for an order-level analysis but wrong if the expected result is one row per customer.
Build the Query in Steps
Start with the main table, add the required joins and filters, and then aggregate or rank the data if needed. As you build the query, explain what each step is doing rather than silently writing the entire solution. This makes your reasoning clear to the interviewer.
Validate Your Assumptions
Before finalising the query, check whether customers can have multiple records, what happens when a value is NULL, whether missing relationships should be retained and whether timestamps are consistent. Finally, make sure the result has the expected grain and number of rows.
SQL Tips for FDE Interviews
Know These SQL Concepts Cold
Be comfortable with INNER JOIN and LEFT JOIN, GROUP BY and HAVING, CASE and COALESCE, along with ROW_NUMBER(), RANK(), LAG(), LEAD(), COUNT(DISTINCT …), date functions and CTEs. You do not need to memorise every SQL function; you need to understand what these tools do and when to use them.
Practise With Messy Data, Not Just Clean Tables
Practise with duplicates, NULLs, missing relationships, conflicting records, multiple timestamps and multiple records per customer. This is closer to the kind of data quality and reasoning problems an FDE may encounter with real customer data.
Explain Your Reasoning
In an FDE SQL interview, explain the logic behind your query in simple terms: starting from business problem, data required, query logic, edge cases and result. The interviewer should understand not only what you wrote, but why that approach answers the problem.
Conclusion
SQL for FDE interviews is ultimately about turning an ambiguous customer-data problem into a reliable answer. Practise these problems with realistic datasets, and focus on explaining why your query works, not just what it returns.
So are you ready to take your FDE preparation beyond interview questions and build the skills needed to solve real-world AI deployment problems? Explore AI Forward Deployed Engineering by IIT Delhi, delivered on Varsity by InterviewBit, through hands-on projects and industry-focused capstones.
Frequently Asked Questions
What SQL topics should I prepare for an FDE interview?
For SQL interview preparation, Prepare SQL joins, aggregation, GROUP BY, window functions, NULL handling, CTEs and date operations. Also understand deduplication, table grain and how joins can affect the number of rows returned.
Are FDE SQL interview questions difficult?
The difficulty depends on the role and interview. FDE SQL questions can be challenging because they often combine multiple concepts and require you to understand the data and assumptions before writing the query.
Why are joins important for FDE interviews?
Customer information is often spread across multiple datasets, so joins are essential for bringing related information together. Know how INNER JOIN and LEFT JOIN behave, especially when matching records may be missing.
Why are window functions important in SQL interviews?
Window functions help you analyse rows within a group without collapsing them into a single result. ROW_NUMBER() can find the latest record, RANK() can identify top customers, and LAG() can compare a row with an earlier one.
How do I handle NULL values in an SQL interview?
Use IS NULL or IS NOT NULL to check for missing values and COALESCE() when you need a replacement value. Also understand how NULL affects comparisons, aggregation and joins.
How should I handle duplicate customer records in SQL for Forward Deployed Engineer interview?
First identify what makes the records duplicates and decide which record should be retained. ROW_NUMBER() is useful when the business rule is to keep a specific record, such as the most recently updated one.
What SQL should I know for AI or Forward Deployed Engineering roles?
Focus on SQL skills that support customer-data analysis and data preparation. Joins, aggregation, window functions, CTEs, NULL handling and date operations are particularly useful when debugging workflows or preparing data for AI applications.
Should I use CTEs in an FDE SQL interview?
Yes, when they make a multi-step query easier to read and validate. CTEs are especially useful when you need to perform one transformation before ranking, filtering or aggregating the result.
Which SQL dialect should I practise for FDE interviews?
Practise the underlying SQL concepts first because syntax varies across PostgreSQL, MySQL, SQL Server, Snowflake and other databases. If the dialect is not specified, clarify it before using database-specific functions.
What should I do if I get stuck on an SQL question during an FDE interview?
Start by clarifying the expected output and the grain of the result instead of immediately writing SQL. Break the problem into smaller steps, explain your assumptions aloud and build the query incrementally. This shows your reasoning even if you do not reach the final query immediately.
