I love to engage with my readers and learn about what their concerns are when it comes to the technical interview. In this article, I’ll go through a question from a reader and 3real SQL questions that were asked during technical screenings from real companies.

The Most Common Reader’s Question: How should I prepare for SQL interviews?

As far as practice questions, you can check out my other article on some of my favorite platforms to use for practice. I would do as many medium and hard problems you have available.

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, so that I can focus and spend my energy on communication and whiteboarding my approach and solution with the interviewer.

In my experience at technical interviews, the biggest focus they are testing for is an understanding of what the code is doing, how you think about the various scenarios/edge cases, and the implications of the results.

The SQL portion is rather easy when compared to the long, complex queries you’d probably write on the job. 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. What makes the interview difficult is linking how the code is written to the result you’ll get if you run the code.

Here are 3 real SQL questions asked during technical interviews:

1st example from a real interview:

You are given 1 table that contains user friend requests, acceptances, and their 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 (hint: use a self-join), but you’ll be additionally tested on the trade-offs of how you write 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? Why?

There’s no right or wrong answer here but you need identify that there are two different ways to write the query and then talk about the trade-offs between those two choices.

2nd example from a real interview:

If you ran an AB experiment and saw a 2x increase in friend acceptance, with a p < 0.05, due to a new feature being launched in pilot regions, do you deploy it to production and launch it to all users?

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 should 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.

3rd example from a real interview:

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?

More advice

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. You’re asked to code something up and think about all the different scenarios and the implications of the results. It can be a stressful situation and most people freeze up.

This is why your technical skills need to second nature. Your SQL skills need to be as good as your English writing skills.

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.

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.