Q&A: How Should I Approach Solving SQL Questions In A Technical Interview?

I love to engage with my readers and learn about their top concerns and questions when it comes to the technical interview process. In this article, I have included a question that I received from a reader about the SQL interview process.

The question that I will focus on in this article cover what you can expect in the SQL technical interview process, as well as how you should communicate this information with the interviewer.

​Let’s get started by learning how you can prepare for an SQL interview, with some specific examples.

Reader's question: How should I prepare for SQL interviews?


In this section, I will give you some quick tips for preparing for SQL interview questions, with some specific examples from Facebook’s interview process.

As far as practice questions, I love to use Strata Scratch because the questions are directly from real companies. I would do medium and hard problems from all the educational modules they have available. There's over 500 SQL questions and I would seriously do as many as possible so that writing queries become second nature. I want the technical part to be the easy part of the interview process, as I would rather focus and spend my energy on communication and whiteboarding a solution with the interviewer.

I’ve gone through a few of the data scientist interviews at Facebook so I can help you with that and give you some insight into what type of questions they asked me.

Here are two examples of the type of questions you can expect:

Type 1

In my experience across a few interviews at FB, the biggest focus they're testing for is an understanding of what the code is doing and the implications to the results.

Technically, the SQL portion is rather easy. You are either given 1 or 2 tables and asked to create a SQL query that requires doing a join or a self-join, or you are given SQL code and asked to debug it.

So long as you understand JOINS and slightly advanced functions like COALESCE, you'll be fine technically. What makes the interview difficult is linking how the code is written to the implications of the question they're asking you. Here’s an example:

Example 1

For example, you are given 1 table that has user friend requests, acceptances, and dates all on 1 table. How do you write a query such that you'll get % of friend acceptances over time?

This query is easy to create, but you'll be additionally tested on the trade-offs of how you wrote the query. How do you deal with a friend acceptance that happened days later? Which day do you count the acceptance? Do you count it on the day the friend sent the request or do you count it on the day the request was accepted? There's no right or wrong answer here but you need to talk about the trade-offs between those two choices.

Another quick example: If you ran an AB experiment and saw a 2x increase in friend acceptance, with a p < 0.05, due to a new feature, do you deploy it to production? Most people would say yes, but in an interview, the most obvious answer is probably not the correct one. The correct one in this case is -- it depends. Then you talk about why it depends and what additional information you would need to make a decision.

​These are all examples of the types of considerations you will be expected to mention to formulate a complete answer.

Type 2

For a second example, you have a master table that contains a user ID and their latest login date, and you have a 2nd table that contains all the users that logged in for that day (there could be multiple logins on that day by the same user). Write a query that will update the master table with the user ID and their latest login date.

Simple enough, but you need to go through the exercise of understanding all the different scenarios. In this case, you have the scenario of a new user that just signed up that day, as well as a scenario where you have multiple logins from the same user for that day. How do you deal with these cases?

I'm sure you're thinking these questions are simple as you are reading this article. But what makes it hard is that you're not expecting these questions during the interview but you're being asked to dissect and solve it on the fly in front of an interviewer. It can be a stressful situation.

Main Advice for SQL Interviews

My main advice to you in preparing for an SQL interview is to understand why and how code is being written to solve a specific problem. Be prepared to communicate why you're writing specific lines of code, what logic you're adding to solve specific edge cases and scenarios, and what the output will yield. Your explanation is just as important (if not more important) than the code itself.

You'll need to know the trade-offs for every metric you're asked to create and how it may impact the question. You'll need to understand all the different scenarios and edge cases and how you can solve them in your code.

Also, be sure to talk with the interviewer as you're building the solution, and keep them in the loop about your thought process as much as possible.

Conclusion

I hope this one example summarizes the main ideas of what you can expect in an SQL technical interview. As you can see, it's mainly testing your understanding and application of the code in various scenarios.

It is perhaps most important that you effectively walk the interviewer through your thought process. Keep them in the loop about what you are thinking at all times. They are mainly testing your approach and your understanding of the technical aspects, and these things can be demonstrated even without a correct answer.

SQL interviews are meant to test your technical skills. Zero-in on the skills that are going to be included in your interview and be sure to do as many practice questions as possible.