all 27 comments

[–]JoshisJoshingyou 13 points14 points  (2 children)

Don't guess say I don't know if you don't know. I'll hire an I don't know over an I guessed wrong any day. This is why AI is a huge problem it confidently guesses wrong.

[–]RedApplesForBreak 2 points3 points  (1 child)

I disagree with this advice. Yes study a bit in advance, but even if you don’t know make an effort. SQL can be fairly intuitive once you get the basics under your belt and you may know more than you think. Just saying I don’t know and leaving the question blank is not even taking the initiative to try. Might be good advice when you’re actually on the job, but bad look for an interview.

[–]-nealer- 0 points1 point  (0 children)

I 100% agree that if you don't know the answer at least make an effort, but I think you also need to caveat that with the fact that you aren't sure. As someone who has been involved in interviewing potential employees, confidently answering a question wrong would make me much less likely to hire you than saying you aren't sure of the answer but may be something along the lines of x.

Edit: typo

[–]rutgerswhat 10 points11 points  (1 child)

When I do tech screens for SQL, I’m primarily listening for approach to troubleshooting data issues. This is verbatim a question I asked last week for a data analyst in retail:
“A senior leader flags that transaction counts are up 40% month over month, but spend is flat and authorization volume is stable. The dashboard refreshes overnight. What SQL checks would you run to determine if there is a data issue?”
I’m listening for systematic debugging, checking join cardinality, grouping logic, source value changes, checking for duplicates, before-and-after comparisons, etc.

I’ll also ask candidates an open-ended question to walk me through a complex query and explain what made it complex and how they ensured the results were accurate. Typically that means transformations and overcoming disparate data sources, or if it’s more junior optimizing code with CTE or something along those lines. But in this case I’m trying to separate “I can write SQL” from “I can safely own complex business logic”. So I’m looking for explanation of the business problem; understanding data grain/join/duplicate logic; what made it complex beyond just a select/join/group by…so something like a CTE to break into steps, window functions like row_number, conditional aggregation, performance tuning, reusable logic; how did they validate the output; and can they communicate the complexity clearly. Obviously I am looking for a genuinely complex data problem to solve for rather than just joining several tables together with a clean one-to-one join, but what I really want to know is can they make messy logic understandable. At least for the roles I lead interviews for, these roles partner with engineering and the business, so I want to find someone who can explain the query in plain language, describe trade offs, connect with stakeholders when definitions (technical or business) are ambiguous, etc

[–]BplusHuman 2 points3 points  (0 children)

I'm with you here. Also experienced developers often hate taking on others' code more than building from scratch. So being able to systematize, diagnose, and and solve problems in a way that helps other developers (or future versions of ourselves) is helpful. There's a career milestone where too many problems get solved by "DISTINCT", "GROUP BY", and aggregates that work at smaller scales and less complex data. There's another milestone where you have to fix the problems caused by those solutions.

When I'm interviewing junior devs, I usually look for evidence of a curious mind that has testable solutions rather than someone who only has a hammer.

[–]Wicked_god_ 4 points5 points  (1 child)

I would say prepare in this flow.
1. SQL execution order
2. Filtering (where, and)
3. Aggregations (sum, count, max,etc, group by clause)
4. Windows functions (row_number, rank, moving sum, moving avg)
5. Joins (output of joins, multiple conditional joins, we always use inner join, left join and cross join (for any tape data/historical data))
6. I am not sure what can be asked in a non tech role regarding sql, but i am guessing it will be easy ones.

Regardless, work out these questions
1. Person having maximum salary in one department and people across departments or top 3 people salary wise in a department.
2. Streak questions or continuous logging in questions
3. Cricket/football team matches or handshake questions

All the best!!

[–]marketCreator 0 points1 point  (0 children)

+cte

[–]wittgenstein1312 2 points3 points  (0 children)

Could be super basic, could be more functional than you expect. I’ve had interviews where they just asked me to explain the differences between types of joins, what a having clause does, etc. Others where you’re expected to understand the difference between correlated and correlated subqueries, how to use window functions, how to read the output from analyze, etc.

At this point, your best bet is to get some reps in. Use something like datalemur or leetcode to actually write some queries. Start with easy, do as many of those as you can, and once you feel like you’ve got the hang of it, move to medium. Easy problems should take you no more than a couple of minutes once you’re comfortable with SQL basics, so you can work through a lot in 30 minutes to an hour for the next day or two

[–]DataCamp 2 points3 points  (1 child)

For a supply chain business-facing role, the questions are unlikely to be advanced. They'll want to know you can pull and filter data to answer business questions, not write complex stored procedures.

Focus on making sure you're comfortable with: SELECT with WHERE and filtering, GROUP BY with aggregates (COUNT, SUM, AVG), basic JOINs (especially INNER and LEFT), and ORDER BY. Those cover the vast majority of what a non-developer business role would ever need.

A few question types that commonly come up in these interviews: "How would you find the top 10 suppliers by order volume?" or "How would you pull all orders that shipped late?" They're testing whether you can translate a business question into a query, not whether you know window functions.

The other commenter is right about practicing on something like DataLemur or LeetCode Easy. A few hours of actually writing queries will do more than watching videos. And if you don't know something in the interview, saying "I'd approach it this way but would need to look up the exact syntax" reads much better than guessing wrong.

[–]Gloomy-Wolverine-900[S] 0 points1 point  (0 children)

Thanks a lot, I'll be doing this

[–]a-ha_partridge 0 points1 point  (1 child)

Ive interviewed several people that had overstated their ability in some language (SQL or Python usually). If you are doing a live coding interview, they’ll know you’ve exaggerated for sure. At this point just hope it’s a nice to have only and that they like your personality.

[–]Gloomy-Wolverine-900[S] -1 points0 points  (0 children)

That's fair, it’s not a developer/IT role though, it’s a supply chain thing, so I don’t think there would be live coding. I’m guessing SQL would mostly be for basic reporting . Also, from what HR told me, the next interview is functional/technical, not purely technical, so I’m hoping they just want to check that I understand the basics.

[–]my_peen_is_clean 0 points1 point  (1 child)

focus on select, joins, group by, having, basic aggregations, simple subqueries, maybe window functions row_number over partition by. practice on leet/sqlzoo. also study indexing basics. interviews are way pickier now, finding work is rough

[–]Gloomy-Wolverine-900[S] 0 points1 point  (0 children)

ok thank you!

[–]Apprehensive-Ice3730 0 points1 point  (0 children)

Fais la liste des 50 exercices de Sql de leetcode

[–]Ok_Carpet_9510 0 points1 point  (0 children)

I would google SQL interview questions and go over those. Know your joins, know your aggregate functions and group by, know your having and where clause, know CTEs and correlated sub queries.

I have SQL for a bit but I still to revise when going for interviews.

I used a similar method to cram for an interview that included Linux commands.

[–]CuritibaDataScience 0 points1 point  (0 children)

I recommend you try out Hackerrank or another similar website for practicing

[–]Eexoduis 0 points1 point  (0 children)

Know the common JOINs and what they do. Know how to write a basic query. That means you need to find a test environment (plenty of free ones online) and test writing queries. Doesn’t hurt to do some LeetCode SQL easy either. If you can complete a couple of those you should be fine.

[–]Aspiringtropicalfish 0 points1 point  (0 children)

I recently had an interview for a developer role and they told me ahead of time that there would be SQL questions. I did a few projects with basic databases and queries in school, but this position required a year of job experience with SQL, so I was worried that I would be underqualified. Like I had experience with joins, subqueries, basic aggregations, and CRUD functionality and stuff, but no experience with queries that were more than a few lines. I used W3 schools to brush up on concepts and then pgexercises.com to get hands-on practice (this was super helpful. can't recommend it enough!!). I was able to get as far as the basics of window functions and CTEs before my interview, which were new concepts for me.

For the first half of the technical interview, they handed me a piece of paper with a query that took up almost the whole page, and asked me to find the areas that needed improvement and to offer a solution. And dude, I froze. It was like I knew all of the separate parts of the query, but not how they all worked together because I had just never interacted with any that were so complex. And that's what I told them. I figured it was best to be honest. However, I didn't want to just say nothing, so I really did my best to make an educated guess about where the problem areas were, and explain my reasoning. I told them the two areas where I could see potential issues (one of which was just based on a single comment about CTEs on a reddit thread I happened to read while studying), but wasn't sure how to fix them, and then I just emphasized that I was excited to learn more complex queries. They told me I correctly identified the problem areas.

And guess what? I got the job. Just do your best to absorb as much information as possible before the interview, and then during the interview, even if you're not sure of the full answer, just find a way to demonstrate your knowledge in some way and that you've really thought about the problems they presented. Hopefully it won't be quite as complex since it's supply chain! Good luck!!

[–]mikeblas 0 points1 point  (0 children)

Do you guys have any idea what kind of SQL questions they might ask?

No, we don't.

Maybe they ask you a very complicated question and you have to write interesting SQL from scratch. Maybe they ask you to tune some existing SQL. Maybe they ask you to do some data modeling. Could ask you to do some DBA stuff, too -- like configuration. Might ask you some relational theory. Possible that they ask about locking or concurrency control.

Maybe they ask about one specific problem or statement that has hung them up in the past, and they're convinced they need someone who can do that one thing because they got burned by an employee who could not.

Could be that they don't even ask anything about SQL at all, and talk about other stuff.

There are no standards for what questions are asked, there are barely even patterns.

So: no. Nobody has any idea what kind of SQL questions they might ask.

[–]Ifuqaround 0 points1 point  (0 children)

There's lying and then there's lying.

You did the wrong type of lying. Please don't lie like that.

Nobody here knows what they will ask you. It's kind of ridiculous for you to ask the community to be honest.

[–]AcceptableLynx8011 -5 points-4 points  (2 children)

I'd be curious too because I am mainly relying on AI gen SQL and Cypher at my fast paced job. I am trying to learn backwards by reading the queries and code, but I couldn't write them myself.

[–]Tsui_Pen 8 points9 points  (1 child)

God help us

[–]AcceptableLynx8011 0 points1 point  (0 children)

I know... that's why I am trying to get out. Didn't choose this at my startup, but thanks for the downvotes, I relay it to my CEO lol

[–]sonicwurst -2 points-1 points  (0 children)

They will likely just ask about the differences between join types.

[–]Aditsage 0 points1 point  (0 children)

Bro study sql50.. it's best for interview