If you're hiring for a SQL developer I guess it makes sense, buit I use SQL about once every 6-12 months or so, so if you hit me with SQL queries on the spot I'll fail your interview for sure.

Honestly, I find interviews that revolve around memorizing and regurgitating some programing language syntax trivia a bit shit.

Wouldn't it be better testing for critical thinking and problem solving skills instead of shit people google anyway?

If I were interviewing for database/SQL work, I'd be personally probing around understanding of the relational data model, not specifics of SQL syntax. How would you model this table? What's a join? What's normalization? What's wrong, conceptually, with the following schema? etc

I think the key insight for you here is that there are many jobs where the only technical skill used is SQL. You probably should know this stuff like the back of your hand for such roles. Old, slow moving, large companies have many people doing this sort of work.

Contrast with a generic "developer" at some startup who uses SQL as only one part of much larger and more complex applications.

As a "developer" you have to deal with so much obscure syntax in your life (actual programming languages, shells, dockerfiles, kubernetes yaml, helm, god knows how many 3rd party APIs, ci/cd definitions, other rando DSLs...) that you won't be able to keep everything in working memory.

But I think that supports the GPs point. At big companies you are more specialized, which means if you get hired into the database dev team you better know SQL really well, cause the non-database devs won't even get access to it and instead depend on you.

I don't expect everyone to have everything memorized or get it right on the first try, but if you don't even know what questions to ask or what resources to confer with, I'm usually concerned if the candidate will be a good fit. The candidate can't be expected to instantly warp to the solution but they need to show they can begin to find the path.

- DDL: create, drop, alter, truncate

- DML: insert, update, delete, call, explain, lock

- TCL: commit, savepoint, rollback

- DQL: select

- DCL: grant, revoke

If you've used them before, you'll have a good enough intuition to understand what each does and when to bring them out of the toolbox. Some database engines have extended versions of these or other ways to achieve the same result, but the underlying concepts are the same.

From there, you should be able to create a basic SELECT statement, and understand the basic flags:

- FROM

- WHERE

- GROUP BY

- HAVING

- ORDER BY

- LIMIT

Then understand joins and how this is all just relational calculus/algebra with sets.

Honestly, I couldn't list these off the top of my head, but I know what each one does when I see them, and I'll instinctively reach for them when I'm writing SQL. But once you know all of this, you know 80% of the SQL you will ever need, and won't have to reach for an ORM. It only takes one weekend to grok SQL, but it will serve you for the rest of your career.

Can't agree on that. If I don't use a language or certain concepts I learned more than 6-12 months, I forget it. Groking something in one weekend that you won't immediately put to use then it gets immediately flushed by the garbage collector. At least for me.

It's like asking a chef to make a hamburger, and telling them how to turn on the grill and where the ingredients are. Either they can do it, or they can't; but you can learn a lot about them by watching them do it.