Comment by runako
20 hours ago
> couldn't even write a basic sql query
Not the point at all, but I have found it quite common among younger professional engineers to not know SQL at all. A combination of specialization (e.g. only work on microservices that do not directly touch a database) and NoSQL has made the skill of SQL more obscure than I would have thought possible as recently as 5 years ago.
Terrifying.
I'm nearly guilty of this. I've been in industry for a bit over 10 years and I can barely write SQL. That's despite writing a bunch of queries by hand in my undergrad databases course. I almost never deal with databases myself outside of some ad-hoc queries.
Same here, mostly because I avoid it because I really do not like writing queries. Something about the syntax rubs me the wrong way, especially if I have to switch from MySQL/Postgres/MSSQL regularly. I'll use an ORM whenever I can, if performances do not matter.
It's because it's logically in the wrong order, it should be:
They use the right order in a lot of ORMs and as I was a SQL expert (but not master), I found it so jarring at first.
You probably have the reverse problem, it doesn't fit your mental model which is in fact the right logical model.
It gets even worse when you add LIMIT/TOP or GROUP BY. SQL is great in a lot of ways, but logically not very consistent. And UPDATE now I think about it, in SQL Server you get this bizarreness:
1 reply →
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.
1 reply →
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.
I started to notice this in a big way at my last job which I started in 2013. We were a rails shop and by about 2016 I was noticing most new hires would have no idea how to write a SQL query.
> most new hires would have no idea how to write a SQL query.
probably why people think rails is slow. our integration partners and our customers are constantly amazed by how fast and efficient our system is. The secret is I know how to write a damn query. you can push a lot of logic that would otherwise be done in the api layer into a query. if done properly with the right indexes, its going to be WAY faster than pulling the data into the api server and doing clumsy data transformations there.
1000%. It’s all about limiting those round trips to the database…
You actually confirmed that rails is slow if the optimization is on the database server and doing data mangling in ruby is less efficient
5 replies →
I see this too, also for engineers that have only interacted with relational dbs via ORMs & query builders
That's so weird to me, SQL is the very first language they taught me in college 20 years ago, before even learning how to write a for loop in pseudo code. Nowadays it's still the language I use the most on a daily basis.
I learned it ~15 years ago, and when I use it a lot it sticks with my pretty well. But if I go a month or two without writing raw queries I lose anything more advanced than select/update/delete/join. I think I forget it faster than other things because none of syntax/semantics aren't shared with anything else I use.
It's a wide field so it depends on the specialization. I did computer engineering 15+ years ago and we never touched SQL, but I think the software engineering people did have a class on it.
I think ORM did a lot of that too
You should at least know how to query your data warehouse environment to debug your services / find out if they're working!
I dont think they teach SQL or relational algebra any more, or at least its easy to get an IT degree and avoid it altogether.