>I have an engineer write some very basic manual SQL data mapping code.
Do people usually have the SQL language so well memorized that they can pull it out of their head on command? I swear to god I'm not the only engineer who regularly goes to the cheat sheet.
> Do people usually have the SQL language so well memorized that they can pull it out of their head on command? I swear to god I'm not the only engineer who regularly goes to the cheat sheet.
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.
Ironically working at a big old company I wrote almost no SQL, because the database was DB2, so we had dedicated Data developers to write stored procedures in COBOL / SQL. While at a small shop and a more modern tech company I wrote tons of SQL.
Same, my best experiences with getting data out of DBs - in an earlier job where I had to work with many external customers directly - were the big ones, cause they always had dedicated Database dev teams that could prepare the data in a way that worked for me and the database. Contrast this with the small shops, which - if at all - had someone as a db admin (usually in addition to their normal job) and could only provide database access and "here, figure it out", which meant I had to write all the SQL myself.
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.
People doing whiteboard coding should not have to get the syntax 100% (or even 80%) correct. It should be enough to just show conceptual understanding of what kinds of syntactical elements and concepts are present in the language. When I trained for giving interviews @ Google, this was emphasized, at least. It's not about getting the syntax exactly right, it's about getting the algorithm right. Though obviously if someone is getting something fundamental wrong, it raises eyebrows.
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
When I give coding interviews I often jump in with "it doesn't compile because you forgot the semicolon at". The tools we use don't make it easy for me to fix such mistakes and it doesn't pay to waste their time to search out a mistake I (as an observer) already happened to know - I want to see their algorithm work so we can move on (or see how they debug why it isn't working yet depending on what phase we are in). I don't really care how long it takes you to find that missing semicolon - we all make that mistake once in a while and there isn't much to learn from it.
As with any language, developers who use SQL a lot do memorize it. Maybe not every bit of it but all the commonly used bits. I used to write SQL and PL/SQL every day at work and I got to the point where I rarely needed to consult the manual.
>As with any language, developers who use SQL a lot do memorize it.
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 you're not hiring a SQL developer I agree it doesn't make sense to ask them memory questions about SQL. But it does make sense to ask them memory questions about whatever it is they claim to know. A developer who has to google the basics is not going to be very good at problem solving.
Any time I've participated in a technical interview as an interviewer we've had the candidate have full access to a computer and web browser.
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.
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.
>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.
I am a SQL wizard and I have to lookup and experiment with the syntax every time I use it. Every engine handles it differently, which is a little maddening.
I provided the query, the skeleton of the function, and I explained the API of a simplified data reader.
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.
Do people usually have the SQL language so well memorized that they can pull it out of their head on command? I swear to god I'm not the only engineer who regularly goes to the cheat sheet.