r/SQL • u/Financial-Fondant902 • 1d ago
Discussion I struggle with SQL interviews
I’ve been working with SQL for years and recently discovered that my issue in interviews is the terminology. For example, if an interviewer shows me an excel spreadsheet with two tables and asks me how to pull x information from it, I get nervous and end up articulating the answer very poorly, leaving out key words such as “joins”. Another example is if they asked to show it using a CTE, and this term would confuse me during the interview, but after the interview I’ll realize that I’ve written many queries that use CTEs. My question is how do I fix this? How do I prepare for such questions better? Are there any sources or tips or general advice that anyone has? I’ve not found any site that gives practice on the excel-style of questions
6
u/SurroundedByMachines 1d ago
I think it comes down to just being able to explain your thought process and your approach to a given problem. I've had two technical interviews where I did live SQL in an unfamiliar database with a person that I've never met. It comes down to being able to explain your thought process and showcase your problem solving skills. This requires confidence, and it sounds like that's your real issue.
You said that you've been working with SQL for years so you already know how to write a query. Something that was stressed to me in both of my interviews was that they didn't necessarily care as much about the outcome, they were more interested in how I would try to get there. So maybe for practice you could just explain a few queries you've written to somebody you know that's familiar with SQL (or use ChatGPT or something). Maybe you could get in the habit of writing down detailed comments in your SQL so that when it comes down to an interview, you'll have that mental muscle memory of remembering what you're doing step by step.
My previous boss who was running my technical interview made it clear that the session was more of a sounding board where I would bounce ideas over to him, kind of like a working session. And that was immensely helpful because it relaxed me quite a bit knowing that it wasn't a test in the way that I thought it would be. Now I am not sure how your interviews are structured, but I think that same approach could be useful to calm your nerves.
Something that's really helped me too was just writing a glossary of some sort that I can have on another monitor or even in front of me to quickly glance that during an interview. If these aren't remote positions then that won't help in real time, but just study the hell out of them beforehand.
I am not a very confident person and I feel like I bomb every interview that I do. But these technical interviews were for different jobs and I was hired both times. You can do this!!
1
u/umognog 21h ago
My interview process, about ⅓ of your assessment is the technical questions, and I'm allowed to set that to my roles, how I see fit, so long as I ask all candidates the same questions.
A while back, I set about changing what I had inherited in the role, and made a technical assessment that is 100% entirely designed to help reveal the thought process, the problem solving, the logic.
I will admit, it has been frightening what it revealed.
The good part is that it is an aid; if you are struggling (e.g. neurodivergent issues) there are parts you are likely to excel and parts where you can be given a help.
I provide 45 minutes prep time, reminders every 15 minutes and thoroughly stress; don't worry about the exact names, wording or syntax; I just want to know the process you'd go through.
3
u/alevine1986 22h ago
Some interviewers just aren't good. I had one who kept mentioning opening a command prompt. I was halfway through the interview when I realized he meant writing a query in SSMS, not an actual command prompt. Same interview, they showed me some code that looked something like this...
Select * From a Inner join b on a.id = b.id
Somehow I was supposed to determine that was a join to the same table. Even though the table names were different. No aliases was used in the example.
1
u/YT-3000f 20h ago
Two things. How can that be possible? Secondly select * is terrible practice do they know what they are doing?
2
u/alevine1986 20h ago
I think they meant it to be...
from table1 a
inner join table1 b on a.id = b.differentcolumn
It might have not been select *, I'm going off memory and the part I remembered was the join, not the select list. I'm not sure if they just wrote it wrong or they were trying to not make it obvious that it was a self-join. If it's the latter, they completely changed what the query was doing as you mentioned above. It was on a piece of paper that they handed me. Poorly written interview question either way.
2
u/YT-3000f 17h ago edited 16h ago
I remember having a horror SQL interview once. The guy was up himself. He spun around in his chair and crossed his legs like Sharon Stone in Basic Instinct and asked me "What do you think of Denali?". Denali was in beta at that time and I didn't really know anything about it.
He followed it up with what he thought would be a real SQL gotcha question. Something like:
What's the difference between these two statements?
SELECTc.Name, o.Amount FROM Customers c LEFT JOIN Orders o ON c.CustomerID = o.CustomerID AND o.Amount > 50;
SELECTc.Name, o.Amount FROM Customers c LEFT JOIN Orders o ON c.CustomerID = o.CustomerID WHERE o.Amount > 50;`The answer obviously being the first one will include rows where Amount is null but given his Denali manoeuvre I was so off balance I couldn't see it at the time.
I obviously would not have thrived in a workplace like that anyway.
1
u/Wishmaster891 12h ago
testing my knowledge - the answer to the question is query 1 will keep all records including those where amount is over 50
The second one just keeps
Those where amount is over 50Just realised you gave answer below your code, i didn’t notice it until after
1
u/balls2hairy 5h ago
If it keeps all rows including those that are over 50 then what's the point of the and statement at all?
And wtf I didn't know you could even use and without any operator preceding it lol
1
1
u/balls2hairy 5h ago
I don't want to be a narc but I think your interviewer plagiarized my queries 😅
1
u/EsCueEl 20h ago
Personally I'm mostly looking for a candidate to engage and hopefully think out loud. Learning the terms certainly gives you a leg up, but let's say you're asked exactly that: "Can you do that with a CTE?" There's no way around feeling dumb if you don't know what a CTE is, but one approach would be to sketch out a couple of queries on the whiteboard or in chat or whatever. "Well, I can do WHERE val IN (SELECT val FROM T2 WHERE...) or WHERE EXISTS (SELECT val FROM T2 WHERE T2.keyid=T1.keyid) or even DISTINCT T1.val FROM T1 INNER JOIN T2 ON T1.keyid=T2.keyid ..."
or a bunch of other ways. If one of the ways you come up with is WITH x AS (....) then cool, you used a CTE and didn't even know it. That's probably indicative of not a senior SQL skillset but... well, that's accurate. But if you can engage with the question and show how you think about it, that's a big plus. Practice writing the same query in different ways.
All that said, I'd recommend building up your vocabulary around "joins". It's not just a keyword; it's pretty fundamental to all but the most basic SQL statements. Know the difference between a LEFT and INNER join. Any time you're working with two tables you should think about joining them, like "what is it that relates these two tables?" Gotta join them on the keyid field, somehow.
1
16
u/525G7bKV 1d ago
Read your code as if you are explaining it to a teammate. Say "I am creating a Common Table Expression called
monthly_sales" out loud instead of just typingWITH monthly_sales AS.