There’s a couple of important details we need to consider in preparing for SQL technical interviews.

SQL interviews are almost always “white-boarding”.

SQL interviews are rarely conducted in a live console where you can run queries in a playground database. Even CoderPad, which is the de-facto interviewing tool for engineers and most tech companies, has only around four example tables you can use– and I’ve never heard of any interviewers using questions from their tables for interview problems.

Why is this the case?

First and foremost, it is difficult to set up a shared environment to test SQL with real data. I also suspect that many companies don’t think it’s a good test if a candidate does have a live SQL playground to work in. For example, Facebook chooses not to create a SQL playground for interviewees to use.

The main reason, however, is that testing SQL by white-boarding SQL syntax allows companies to assess real mastery of the language that is also practical for speaking towards your efficiency as an individual contributor.

If you’re working at a company with large swaths of data, your queries are likely to be slow. My co-workers and I on the data science team would write a query, go to the snack bar across the office and walk back, and it still would not be done. There was just so much data we had to query.

Running queries generally takes a long time, which is why getting it right on the first try is a good demonstration of general competence.

Imagine running an expensive join and waiting an hour until it times out just from non-optimized code. You likely just got blocked on a task for a whole hour during the workday. Then, imagine again an hour-long SQL query that comes back with wrong data because you messed up a simple join.

And ultimately, these scenarios are better than the worst-case scenario where you write a wrong query, put it into an ETL job, and then be comfortably oblivious as your company ingests wrong metrics for who knows how long. The point being, learning how to write correct SQL is very important, and the expectation is that you can whiteboard it without too much failure.

SQL is a skill that can be learned efficiently.

One can improve their SQL ability by simply practicing. The steps towards mastering SQL include repeatedly working on problems, aka Leetcoding. Unlike Leetcode and other programming interview questions, however, SQL interview questions are more similar to the tasks that you will do on the job as a data scientist, which, on the plus side, means that mastering SQL can sometimes consist of you doing your actual day job.

However, the downside is that if your role is specialized and you’re restricted to only using SQL for something like time-series forecasting or you don’t use SQL on a day-to-day basis, you can’t practice it effectively across the board for interviews.

Therefore, the unique problem sets that we provide on Interview Query allow you to hack the learning curve of SQL experience and master the querying language.

Our job within this course is to expose you to the most common types of SQL questions that data scientists have to work on. Examples include everything from practicing applied analytics to dash-boarding metrics to queries for model and dataset generation.