SQL interview questions can be bucketed into easy, medium, and hard. Each level of difficulty tests different types of concepts.

Use Interview Query to level up at how good you are at SQL. Here’s how you should approach each problem.

1. Try the SQL question without running any SQL code in the engine. Give yourself 15 to 20 minutes to work on each problem by just reading the problem statement and using the editor.
2. Work out all the bugs and make sure that when you click run, you feel like this is the definitive solution that will work without syntax errors.
3. If you get stuck, try the problem hint. The hints on certain questions will push you into learning how to think about solving the problem at hand.
4. Run your code and check for syntax errors. If you get any, re-read your query to fix the necessary errors.
5. Check your solution against ours. Take note of whether there are any optimizations you can use to write a more efficient query.

Easy SQL Problems

Basic SQL joins, aggregations, and functions. Imagine questions that involve getting the COUNT of a table, knowing what the HAVING clause does, and figuring out how to utilize LEFT JOINS versus INNER JOINS to give you the values that you need.

Medium SQL problems

Medium level problems test more complex analytics and metrics that we would want. Imagine a dashboard of metrics that you would want to track. How do you get the number of daily, weekly, and monthly active users by platform or geography? How would you calculate customer churn for different products?

Medium level problems test your understanding of advanced SQL concepts integrated into metrics. This means using sub-queries, self-joins, cross-joins, and aggregation functions on top of CASE WHENs, all to get the data or values that you need.

Hard SQL problems

Hard problems come up more often than not during many interviews. These are designed more to potentially test how you would think about solving a problem and are purposely left more ambiguous than other types of problems. The toughest thing about hard SQL problems is the fact that you not only have to think critically about what the SQL output has to look like, but you also need to understand EXACTLY what the right data points you want are.

For example, an interviewer might ask you to write a SQL query (given a few tables) to understand which AB test variant won. There might not even be any understanding of what “winning” actually means.