Maybe this makes me a grumpy old man, but I feel like if you're primary role is to write software which interacts with a SQL database you should understand how to interact directly with that database. Not because you're going to do it frequently, but because understanding the thing your ORM is abstracting away for you allows you to more intelligently use those abstractions without making whoever runs the underlying database cry.

▲

switchbak 6 days ago | parent | next [-]

One of the things that taught me the most about SQL is trying to use Hibernate (There's not enough expletives in the english language to describe that thing).

It's one thing to have a query language (DDL and DML no less) that was built for a different use case than how it's used today (eg: it's not really composable). But then you stack a completely different layer on top that tries to abstract across many relational DBs - and it multiplies the cognitive surface area significantly. It makes you become an expert at Hibernate (JPA), then learn a lot about SQL, then learn even more about how it maps into a particular dialect of SQL.

After a while you realize that the damn ORM isn't really buying you very much, and that you're often just better off writing that non-composable boring SQL by hand.

- assuming you have a decent testing infrastructure in place. Much of the supposed benefit of ORMs is about a form of psuedo-type safety, and making it easier to add more fields. If you have fast running tests that exercise the SQL layer, you might find those benefits aren't very compelling since you have such rapid feedback for your plain SQL anyway.

I've almost never changed the vendor of DB in a project, so that's another supposed benefit that doesn't buy me much. I have often wanted to use vendor-specific functionality however, and often find an ORM gets in the way of that.

To sum it up - I agree completely. If it's your job to wrangle an SQL DB - you ought to learn some SQL.

	▲	abustamam 5 days ago \| parent [-]
		Can you explain this part to me? > assuming you have a decent testing infrastructure in place. Much of the supposed benefit of ORMs is about a form of psuedo-type safety, and making it easier to add more fields. If you have fast running tests that exercise the SQL layer, you might find those benefits aren't very compelling since you have such rapid feedback for your plain SQL anyway. "decent testing infrastructure" is kinda doing a lot of heavy lifting — I love TDD but none of the startups I've worked at agreed with my love of TDD. There are tests, but I suspect they wouldn't fall under your label of decent testing infrastructure. But let's say we do have a decent testing infrastructure — how does this solve the type safety benefit that you mentioned?

▲

hobofan 6 days ago | parent | prev | next [-]

> because understanding the thing your ORM is abstracting away for you allows you to more intelligently use those abstractions

If that's required, then you are working with a bad abstraction. (Which in the case of ORMs you'll probably find many people arguing that they are often bad abstractions.)

▲

abustamam 6 days ago | parent | prev | next [-]

I agree in a sense but I'm primarily a front end dev. Our backend devs (whose SQL skills are probably on par with mine) maintain the DB tables and such using our ORM but I would still need to use the ORM to query the DB. I'll hop in and make a DB update on the backend if I need to, but my point is that many front end devs are probably just using the ORM to query and run mutations. Such queries could certainly be optimized a bit by knowing a bit of SQL (adding indices to commonly queried cols for example) but I'd still consider solid knowledge in SQL to be a solely backend thing.

That said, I do know enough basic SQL to understand what ORMs are doing at a high level, but because I almost never write SQL I wouldn't consider myself proficient in it.

▲

cutemonster 6 days ago | parent [-]

It'd been nice if the interviewer had informed you in advance that they were going to ask you to write SQL, so you could have prepared? Or you could have saved some time by cancelling? Why don't more companies do that

	▲	abustamam 5 days ago \| parent [-]
		The screening call had some sql questions which I was able to answer. Basic sql. I feel like I could have saved a day of interviewing if this simple fkey question was in the screening. Companies should do that more!

▲

Fervicus 6 days ago | parent | prev | next [-]

> if you're primary role is to write software which interacts with a SQL database you should understand how to interact directly with that database.

I agree that there should be a general understanding one should be able to interact with it when needed. But at the same time I don't think devs need to be able to spit out queries with the right syntax on the spot in an interview setting.

	▲	jon-wood 5 days ago \| parent \| next [-]
		Unless I'm doing an exercise where the candidate is actually writing software (in which case they can have Google, their favourite IDE, and if they must an LLM) I never expect exactly correct syntax in an interview. I'm assessing whether they demonstrate the sort of thought processes you'd expect from someone who knows what they're talking about, and can get in the same ballpark.
	▲	cultofmetatron 5 days ago \| parent \| prev [-]
		in our particular case, they could use google. that said, I didn't ask them anything particularly complex. the AI depndant coders(I saw nothing in their abilities that demonstrated engineering) broke down trying to update a single record of known id with a new value.

▲

Rapzid 5 days ago | parent | prev [-]

Not everyone wants to make that much money.