Comment by abustamam
11 hours ago
I've been a full stack engineer for 10 years and I know SQL syntax but a few years ago I was asked at an interview "make a relation between users and posts" and I went "rails generate user" or something, and he's like, "not that," so I was like "OK I'll add it to a prisma file" and he's like "not that, write the SQL. I dunno what to do because this has never happened before."
Needless to say, I did not get the job, but several years later I still don't know how to answer his question.
I've worked with NOSQL (Mongo/Mongoose, Firebase) and I've worked with ORMs (Prisma, drizzle, Hasura), and I've been able to implement any feature asked of me, across several companies and projects. Maybe there's a subset of people who really do need to know this for some really low level stuff, but I feel like your average startup would not.
I think maybe it's similar to "can you reverse a linked list" question in that maybe you won't need the answer to that particular question on the job, but knowing the answer will help you solve adjacent problems. But even so, I don't think it's a good qualifier for good vs bad coders.
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.
> 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.)
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.
I guess this is my first old-senior moment, but even if you use an ORM then you should know basic SQL. That table structure will be the most long-living thing in your system and probably outlive the ORMs and a bad table structure is going to create a mess later on.
I agree. I know _basic_ SQL but because I don't work with it every day I don't consider myself proficient. I read the migration files generated by my ORMs just out of curiosity and to make sure it's not doing anything crazy, but I wouldn't be able to write the migration file myself.
All projects I worked with, that used ORM, were burning pile of shit and ORM was a big part of this. I hate ORM and would prefer SQL any day. In my projects I almost never choose ORM.
I trust that some people can deal with ORM, but I know that I can't and I didn't see anyone who can do it properly.
So, I guess, there are some radical views on this issue. I wouldn't want to work with person who prefers to use ORM and avoids know SQL, and they probably hold similar opinion.
It is really weird to me that someone would call SQL low level. SQL is the highest level language available in the industry, definitely level above ordinary programming languages.
Interesting. The reason I like ORMs is because of type generation in TypeScript. I've never worked in a company that didn't use an ORM which is likely why I prefer it. But if I ever did work in a company that used raw SQL I'd probably just suck it up and learn better SQL. Maybe then I'd be able to make a more informed opinion.
With regards to SQL being low level, I primarily work with TypeScript so a language that talks directly with the DB (SQL) seems pretty low level compared to TS. I'm not sure what you mean by an ordinary programming language though (obviously not machine code).
I would assume he means creating a foreign key relationship from the posts and users table. Doesn't rails or prisma have a SQL migration tool? (Upon looking it looks like it's Active Record)
So the equivalent of
`rails db:migrate` after doing what you suggested in the interview. You could write in SQL as..
``` ALTER TABLE posts ADD COLUMN user_id INT, ADD CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(id); ```
I don't know if that's what he was after but that's what my mind jumped to immediately. I'd recommend learning a bit as sometimes I've found that orms can be a lot slower than writing plain SQL for some more complex data fetching.
Thanks! I think I was (conceptually) missing the constraint/references part. Prior to that I had only worked with firebase and Mongo so I was just like "OK so I just put userID column on post table right?" and apparently no, not right, lol.
What's nice about prisma and hasura is that you can actually read the sql migration files generated, and you can set the logging to a level where you can read the sql being run when performing a query or mutation. I found that helpful to understand how sql is written, but since I'm not actually writing it I can't claim proficiency. But I can understand it.
I’ve written manual SQL for years in previous roles, but because I haven’t touched it in 6 months I’d have had to double check how to write that with a quick google. It’s just a bad interview technique to require write learned syntax.
I agree but lots of companies do similar things in their interview processes so we just have to know everything I guess.
One thing is reversing a linked list during a white board interview. Another write a simple JOIN between two tables.
Come on guys, working on backend applications and not having a clue about writing simple SQL statements, even for extracting some data from a database feels...awkward
With NOSQL becoming more ubiquitous (for better or worse), it's not unfathomable that someone simply never had an opportunity to do something as simple write a join between two tables. Someone replied to my comment and taught me how in 5 lines of code. I read it and I'm like, oh that makes sense. Cool. I won't remember it exactly but I understand it. I wouldn't hold it against a front-end developer who's only ever worked with Vue to understand what happens when a React node rerenders.
My point is that there are acceptable levels of abstraction in all parts of software. Some companies will have different tolerances for understanding of that abstraction. Maybe they want a front-end dev to understand the CSS generated from tailwind. Or maybe they want them to know exactly what happens when a React node is rerendered. Or maybe the company doesn't care as long as the person is demonstrably productive and efficient at building stuff. What some consider basic knowledge can be considered irrelevant to others. Whether or not that has lasting consequences is to be seen, but that just brings us full circle back to the original problem at hand (is it good that people can vibe code something and not understand the code it generates)
Wait, people still unironically use ORMs instead of writing queries directly? Not surprising then that everything works like shit
Every startup I've worked at has at least done their first few MVPs using an ORM. I imagine because it's just a quick way to bootstrap a project. Since performance isn't really an issue before scale, sql vs ORM is just a matter of dev velocity, but I guess at scale most companies just never repaid the tech debt.