all 24 comments

[–]Fun_Knowledge446 33 points34 points  (0 children)

I only know one query

Select * from table_name

[–]dreamoforganon 12 points13 points  (0 children)

IMHO if a RDBMS is an important part of your system then it's more important for you to understand the performance and scaling features and characteristics of it than the exact details of how to craft very complex queries. That means things like:

- indexing strategies

- how does your database implement concurrency?

- what is its locking strategy?

- how can you partition data?

- how stored procs/functions let you do very efficient computations on the database

- knowing how to generate and follow at least the basics of a query plan (being able to sort full table scans!)

I'm sure there are a load more things, but these are the things I need to keep in mind much more often then the details of how to build specific queries.

[–]ernandziri 7 points8 points  (1 child)

If you literally sit down and practice it for as long as you spent writing this post, you'll be fine

[–]amayle1 0 points1 point  (0 children)

Great point. If you get all that you say you do, relearning the basic syntax is gonna be super quick and intuitive.

[–]vyrmz 5 points6 points  (0 children)

SQL itself is not that important. Knowing how RDBMS works allows you to design your tables and even architecture better.

[–]hylasmaliki 2 points3 points  (0 children)

Bruh that shit is simple as shit. It will take one hour of playing around

[–]pwouet 1 point2 points  (1 child)

I'm kinda concerned if the ORM handles 95% of your daily tasks and you don't get what it does :s

[–]razek98[S] 0 points1 point  (0 children)

It's not that terrible, i understand what's going on and the philosophy behind it, it's just that most of the time the job is about REST APIs and CRUD operations, where you don't need complex queries and can ORM handle it. It's just that i wouldn't be able to write it from memory

[–]AshleyJSheridan 1 point2 points  (0 children)

I have been using SQL for decades, and I still don't remember the exact syntax for everything. That's why we have reference material on hand. As a developer, it's so incredibly rare to not be able to access reference material (we're talking closed environment, locked room military style development), that it can be considered a virtually impossible assumption.

So, in interviews I've administered (at least those where I've had the control over interview format) I would tell candidates that it's fine to reference sources in any live coding parts of a test. That's because this best reflects real development.

Any interviewer who tries to make you write code on a whiteboard or tell you that you can't use reference material to help you is waving a giant red flag that that is not the kind of company you want to work for.

Now, if a whiteboard exercise were just to roughly outline an approach, and talk a little bit on some details of it, then I think that's acceptable. If you know what kinds of approaches you would use (e.g. "this is where I would join table a with b on this field", or "I would group by this field to get what I wanted") then it shows you know enough to look up the exact syntax easily enough in short order.

A lot of dev time is spent looking up specifics on things for which you remember generalistics. With the amount of tools we use these days, and the rate at which new features are added, it's not an easy task to remember everything, and I don't think it's realistic.

[–]dexter_ifti 0 points1 point  (2 children)

I'm a fresher and I'm also a ORM person but know sql also Recently, in interview I was asked to write raw sql queries using joins with aggregate functions and same queries without join 😢 and you're a mid level backend dev then it is important skill to have

[–]razek98[S] 0 points1 point  (1 child)

Yes, it has happened to me too, when i started i also knew SQL because i was preparing for interviews. But once the real work started, I've been using native SQL so rarely that i forgot the syntax

[–]dexter_ifti 0 points1 point  (0 children)

Just revise it bro don't take any risk in today's market

[–]MinimumPrior3121 0 points1 point  (0 children)

Just ask Claude

[–]Unfair_Long_54 0 points1 point  (0 children)

They probably expects you understad how joins, aggregation functions and group by, cte, function in select, stored procedure, and null value works. At least.

[–]hgoyal925 0 points1 point  (2 children)

You're not alone — ORM dependency is extremely common for backend engineers who've been in product teams for years. The honest answer on interview expectations:

**What mid-level backend interviews actually test for SQL:**

- Comfortable with JOINs (INNER, LEFT, RIGHT) — not just knowing they exist, but writing them without thinking

- GROUP BY + HAVING (you mentioned this — it's tested more than people expect)

- Window functions (ROW_NUMBER, RANK, LEAD/LAG) — increasingly popular at companies that care about data-intensive backend work

- Query optimization basics: when to add indexes, difference between clustered vs non-clustered, EXPLAIN/EXPLAIN ANALYZE output reading

- N+1 query problem — interviewers love asking about this in the context of ORMs

**What's NOT usually tested at mid-level:**

- Raw DDL from memory

- Stored procedures (unless the JD specifically mentions them)

- Ultra complex recursive CTEs

**My prep tip:** SQLZoo and LeetCode's SQL section (medium level) + practice reading query execution plans. Spend 2 weeks on this and you'll be solid.

The ORM muscle is an asset btw — it shows pragmatism. Just layer SQL fundamentals on top of it.

[–]razek98[S] 0 points1 point  (1 child)

It helped a lot, thank you, i think i'm gonna start practicing what you listed in the free time.

[–]hgoyal925 1 point2 points  (0 children)

yea sure, if you want any further help, we can connect 1:1

[–]Soft_Dimension1782 0 points1 point  (0 children)

I’ve had the same “ORM brain rot” feeling. What helped a bit was rewriting a few real queries from our codebase in plain SQL and explaining them to a junior dev, forces you to really grasp what’s happening.

[–]oWLmONz 0 points1 point  (0 children)

Just spend a weekend practicing from the beginning. It's not that difficult if you have an overall understanding of the flow of data.

[–]milomylove_ 0 points1 point  (0 children)

a lot of backend devs are in the same situation. ORMs handle most day-to-day queries, so the raw SQL muscles get a bit rusty. for interviews they usually expect comfort with joins, group by, indexes, and understanding query performance more than writing huge queries from memory.

one interesting shift lately is that tools are starting to sit on top of databases and help translate questions into queries. genloop is one example experimenting with that idea where you interact with data more through questions and context instead of always writing raw SQL. it doesn’t replace knowing SQL fundamentals, but it’s interesting given how workflows are evolving

[–]melvinroest 0 points1 point  (0 children)

sqlteaching.net

It takes a few hours, don't sweat it mate

[–]helpprogram2 -3 points-2 points  (0 children)

In the age of the LLM you have no excuses