How to Crack the SQL Round in a Data Analyst Interview

What Interviewers Are Actually Evaluating

Most candidates focus only on getting the right answer. But interviewers are watching for four things:

• Can you read an unfamiliar schema and understand relationships between tables?
• Do you write clean, readable SQL — or one giant nested mess?
• Do you think out loud and explain your reasoning?
• Do you verify your result makes sense before saying you are done?

The 5-Step Framework for Every SQL Interview Question

Step 1 — Read the Schema Before the Problem

Before reading the problem, spend 60 seconds on the schema. Identify: what are the tables, what are the primary and foreign keys, what data types are the key columns. Most mistakes happen because candidates misread the schema.

Step 2 — Restate the Problem in Your Own Words

Before writing any SQL, say out loud: "So what we need here is..." This confirms you understood correctly and gives the interviewer a chance to correct you before you go down the wrong path.

Step 3 — Plan Your Query in Steps Before Writing

For any non-trivial question, plan the approach first:

• Which tables do I need?
• What is the JOIN condition?
• Do I need to aggregate or use a window function?
• Should I use a CTE or subquery?

Step 4 — Write Clean SQL Using CTEs

Write your query using CTEs to break the logic into readable steps. Even if a subquery would work, a CTE shows maturity and is easier to debug. Structure it as:

• CTE 1: Get the base data with any filters
• CTE 2: Apply aggregation or window functions
• Final SELECT: Format and output the result

Step 5 — Verify Your Result

Before saying you are done, do a quick sense check:

• Does the row count look right?
• Are there unexpected NULLs?
• If you used RANK(), is the ranking ordered correctly?
• Does the output match what was asked — column names, sort order, etc.?

The 6 Most Common SQL Interview Patterns

Pattern 1 — Top N per Group Find the top 3 selling products per category. Uses ROW_NUMBER() or RANK() with PARTITION BY. This pattern appears in most analyst interviews.

Pattern 2 — Running Totals Calculate cumulative revenue over time. Uses SUM() OVER (ORDER BY date).

Pattern 3 — Month-over-Month Comparison Calculate the percentage change in a metric between months. Uses LAG() to access the previous month value.

Pattern 4 — Retention / Cohort Analysis Find users who came back after their first session. Uses self-joins or window functions with date comparisons.

Pattern 5 — De-duplication Keep only the most recent record per user. Uses ROW_NUMBER() PARTITION BY user_id ORDER BY created_at DESC, then filter WHERE rn = 1.

Pattern 6 — Funnel Analysis How many users completed each step of a process. Uses conditional aggregation with CASE WHEN or COUNT(DISTINCT).

Common Mistakes That Fail Candidates

• Writing the entire query in one nested statement — use CTEs instead
• Forgetting to handle NULLs in JOIN conditions
• Using WHERE instead of HAVING after GROUP BY
• Not aliasing tables in multi-table queries — makes the query unreadable
• Returning all columns with SELECT * — always specify the columns needed
• Staying silent while writing — narrate your thinking throughout

Frequently Asked Questions

Should I memorise SQL syntax for interviews? Know the core syntax by heart but focus more on problem-solving patterns. Interviewers care more about your approach than perfect syntax.

What if I get stuck during the interview? Talk through what you know and what you are trying to do. Interviewers would rather help a communicative candidate than watch a silent one get stuck.

Are SQL interviews timed? Yes, typically 20–30 minutes per question in a live coding round. Practise solving medium-difficulty problems within a 20-minute limit before your interviews.

Do I need to optimise my SQL query during the interview? Not usually at the analyst level. Write a correct, readable query first. Only discuss optimisation if the interviewer asks.

Where can I practise these SQL interview patterns? TheQueryLab has challenges built specifically around these patterns — Top N, running totals, cohort analysis, and funnel problems — modelled on real company interviews.