linkedin Skip to Main Content
Just announced: CoderPad Play! Engage your team with fun technical challenges.
Back to blog

SQL Interview Questions

Interviewing

How to Structure SQL Interview Questions

If you’ve ever interviewed technical talent, you know that the pressure is on to accurately assess candidates’ skills, experience and fit.

A technical interview is the classic way to jumpstart this process. But is your approach one that gets you the answers you need while also putting your best foot forward to top candidates?

To get the inside perspective on running a brilliant SQL-focused technical interview, and evaluating candidates, we had a chat with two experts: Wendy Lu, Growth Analytics Lead at Figma, and Jonathan Geggatt, VP of Engineering at CoderPad (and formerly Head of Data at Airbnb).

Here’s what they told us.

Mine the real world for scenarios that resonate.

Candidates already practice the SQL interview questions that pop up in a basic Google search – so how useful is it to ask them?

That’s why leading companies are increasingly moving away from generic questions and are instead offering candidates a crack at real-life internal scenarios. “At Airbnb, we gave potential hires access to the tools we use and a vetted data set, one where we knew its limitations and problems. It allowed them to focus on the shape of the data and frame answers to problems that were meaningful to us,” notes Geggatt.

Lu agrees that a case-based interview is optimal. “I’m not hung up on the hardest questions but the ones that are most relevant for the business problems we’re working on day to day,” she says. “More companies are looking inward for case-based questions because they’re good for holistic testing. They can help candidates show critical thinking, technical skills, business acumen, and communication ability.”

Yes, it’s obvious but ensure you’re testing for skills that fit the candidate’s experience level.
SQL doesn’t have a ton of conceptually challenging elements to test for, says Geggatt. He structures interviews to determine if a candidate’s stated experience aligns with reality as well as what’s needed for the role. For instance, an entry-level person should understand the different kinds of joins whereas someone mid-level should easily show a solid grasp of window functions and aggregations, plus how they work together and when they’d be useful.

For senior level candidates, he says throwing in a dirty dataset, one in which a prospective hire can’t be sure the data quality is top notch, is a good way to assess higher-order skills. Watch how well they clean it up – removing dupes, for instance, or casting currency into numbers instead of strings. Manipulating data to improve the fidelity of a dataset is a typical real-world scenario.

Offer problems that require conceptualization and application.

If you’ve game-planned it well, candidates won’t be able to nail a technical interview by cramming for it like a test. Place a premium on candidates’ ability to intelligently apply concepts, not how well they parrot back the basics. In a SQL interview, you might ask them to:

  • Take a large dataset and join it to a clean dataset. For example, the user’s table might be clean but the analytic events table could have issues. Perhaps it’s something relatively basic like the ID on the user’s table is an integer but on the other, it’s a string. Ask for insights like how many times a user visited the site in the last three months. In a more complex advanced example, you might challenge prospective hires to develop a 360-degree view of customer behavior around events like payments and site visits. Query them on specifically how they would get answers.
  • Demonstrate the difference between actions like filtering an “on” clause versus the “where” clause in a join. This can indicate the extent of their knowledge around order of operations within joins. Do they know the result of null equals null? Questions like these can help you gauge curiosity around niche concepts.
  • Walk you through table relationships, specifically ordinality and cardinality. Do they know inner and outer joins? Can they talk about order of operations because they understand how SQL processes these operations?

Set expectations.

A technical interview bears some similarity to grade school: you want candidates to share their thinking, show their work, and raise their hand as needed throughout the process. So set that expectation up front – and also make it clear that you expect them to dig a little deeper into each problem.

“Technical interviews aren’t always straightforward. Candidates should assume there’s a level of nuance to what we’re giving you,” advises Geggatt. “They should be thinking about what you might be implying or even what could be missing before jumping into the answer.”

Similarly, you’ll want to see if a prospective hire is willing to ask questions if they get stuck along the way. “It tells you a little bit about what that person might be like to work with – if they’ll barrel ahead or connect with their team,” he says.

Lu emphasizes that a willingness to ask questions is a positive. “Sometimes candidates will sit for five minutes and won’t ask questions,” she notes. “That’s a red flag around communication. Sometimes it’s that they don’t want to look stupid but there’s no perfect answer. It does show how this person would potentially work on a team. I want to know the assumptions they’re making along the way so I can correct them and keep the interview moving forward.”

Remember it’s about so much more than just their technical skills.

How a candidate approaches a technical task is as important – if not more important – than actually getting an answer that’s textbook perfect. As a hiring manager, try to evaluate critical thinking skills as well as the ability to problem solve.

“I’m looking for someone who’s professionally skeptical about the datasets they’re working with,” says Lu. “Are they addressing data hygiene? Are they thinking about data structure before jumping right into analysis?”

A typical SQL test could have three or four “correct” answers so don’t get hung up on the idea there’s only one impressive response. The metric should be, Can this candidate write queries that will generate a meaningful answer for a real business case? Evaluate how well that person then communicates it. People who can articulate the assumptions they made during the analysis – and then convey the results to technical and non-technical audiences alike – should rise to the top of your heap. For example:

Look for the candidates who put in extra effort.

Candidates should know a decent amount about your company. That’s just table stakes. But give major bonus points for those who use that information creatively, say, by finding and extrapolating typical use cases. Do they have a point of view on what the company is trying to optimize for? A sense of the challenges could they use data to overcome? Mention how competitors are approaching the same issues? Those are great signals you’ve got a winner on your hands.

Ultimately, SQL is a tool that many can pick up. But beyond mastering the functionality, hiring managers should design the interview to ensure they get a full-spectrum view of candidates: from critical thinking and communication skills to generating useful results.

More interviewing resources

We have made available these extra resources to improve your SQL coding skills: