How to approach SQL problems during a technical interview for a Data Analytics role
These days it’s very common for an interview cycle for Data Analytics or Data Science roles to include a technical round that covers writing SQL code. It might seem very straightforward — you’re presented with a hypothetical or real data table and asked a series of questions from which you’ll write SQL queries that will get the correct answer.
However, it can be very stressful to actually write the code live while someone is watching. Additionally, even if you write SQL queries all day, being asked to write a query for a data table you’ve never worked with or even looked at, for a business problem you’ve never thought about, for an industry you may not be familiar with, with the clock ticking against a time limit … this can be very challenging.
In addition to doing practice problems in advance on sites like Interview Query, Dataford, or StrataScratch, it’s important to have a framework that you use during these interviews.
I use the overall framework — keep reading for more details for each step.
- Understand the question and the data.
- Ask clarifying questions.
- Decide on the structure for my approach.
- Write my code in an iterative way.
- Explain my code.
- Share my assumptions, trade-offs, or edge cases.
Understand the question and the data
Before jumping in, make sure you understand what you need to do and what data you are working with.
If you’re working in a pair programming environment (like Coder Pad) where you both can see what the other person writes, often the interviewer will write out the schema for the data tables you’re using as well as each question you need to answer.
I always keep a Google Doc open during interviews, so if they don’t write out the question for me, I will write it out for myself in my Doc.
Before I start writing anything, I take a minute to review both the question and the schema to make sure I am clear on the task at hand.
Ask clarifying questions
While you are reviewing the question and data and before you start to solve the problem, clarify your assumptions and ask questions about anything that is not clear to you.
This is something you should do when you are on the job, so you need to demonstrate that it is part of your process. Even if everything seems clear to you, restate in your own words what the interviewer is asking, and ask if your understanding is correct.
Things I typically want to check in the schema and/or clarify— which values are unique? What are the foreign and primary keys (if it’s not already identified)? Should I expect NULLs in any columns? If data types aren’t listed, state your assumptions and verify.
Decide on the structure for my approach
Before writing any code, it is usually a good idea to think through the structure of your query. If you’re joining tables, think about what columns you’ll join on and the type of join. Think about what data you need from each table. Think about how you want to aggregate the data and how you’ll group it. Think about any calculated columns you need to create. Double-check that the data types are usable for your approach.
Often, I like to summarize my approach out loud and ask the interviewer if they think that sounds good. This is especially a good idea if they stress that this is a pair programming exercise or meant to be collaborative —demonstrate that you can collaborate.
Write my code in an iterative way
Finally, it’s time to start writing my code. Because I’ve already laid out my structure, this step should be a little less intimidating.
If I know that I am in an environment where I can actually run my query and get a result, then I might use that during my process, to check my data or iterate along the way. I talk through my process so the interviewer understands that is what I’m doing.
If I get stuck , I ask for help or ask if I can look something up (via Google/Stackoverflow/etc). In some cases, they have structured the interview to anticipate common questions and have hints or code snippets ready should you need them — especially if this is meant to be pair programming or collaborative. Otherwise, usually, they are fine with you looking up something, after all, this is normal to do on the job, and they want to see how you would solve problems on the job.
Explain my code
I typically code out loud during interviews— I explain what I’m doing while writing my code.
For example:
- “I’m doing a left/inner/whatever join because …” — they’ll often ask you why you used the join you did anyway.
- While writing your WHERE clause: “I’m only including data that meets X criteria because …”
- “I’m creating a column that is X divided by Y because …”
When I am done writing my query, I’ll announce that I’m done and summarize what my query does, and then if we’re in a live environment, run my code.
Share assumptions, trade-offs, or edge cases
You can also continue to ask questions while writing your code, including verifying more assumptions that come to mind.
You should also clarify any edge cases or trade-offs you’re making while writing your code. Often, follow-up questions from the interviewer include these, so it is good to show that you are already thinking about them.
How do you approach SQL assessments during interviews? Share any other tips that you have!
Need more help? Check out my full Data Analytics Interview Prep Guide.
Want more career advice? Follow me on TikTok, Instagram, or LinkedIn, and sign up for my free data career newsletter.
