Yes, Software Engineers MUST Know SQL

[@1EFeKT1]

From my 15+ years of experience of being a software developer - SQL is needed. Not to a Data Analyst or a DBA level, but good enough to write or at least understand complex queries. And it shouldn't be too hard to understand, as where most coding languages develops and change, SQL pretty much stays the way it is, with most differences being server-specific (i.e. MySql vs MSSQL).

[@BTimelessC]

Can I ask what constitutes as a complex query though? Because I have heard this a lot and I really don't know what it means, isn't complex a bit of subjective here? For example I've been working almost 4 years as a developer and I have worked in 4 different companies, SQL was always part of it I agree. But in some cases I just had to do simple queries (Select, Update, Create tables or views etc) in other cases I would have to do Triggers/Stored Procedures create different indexes for performance or data integrity etc... Some would argue that a select with a join is complex, others would say a procedure is simple. So where is the line I guess is my question according to you who have 15+ years of experience?

[@markusjohansson6245]

Other than the basics of crud, I think knowing joins without having to google is ok. Knowing about indexes and relations, fk etc. Can google the rest.

[@1EFeKT1]

​@@BTimelessC As mentioned here by *markusjohansson6245* , knowing how and when to use the different JOINs is a must, and as for complexity level - you should know how to make more than basic actions on the input or output of the queries (such as substring, concat, str, sum, count, etc.). This is a good place to start, and with time build enough knowledge to use expressions such as HAVING and WITH (or your SQL version of choice equivalent). The reason is not to just be able to understand queries that are written by colleagues, but to move the burden of computation from your code and onto the SQL engine, which is made to do such complex actions on tables and data and most of the time is more suitable for doing so efficiently.

[@ipiptr]

​@@BTimelessC have you ever work in manufacturing company? there are some complex query, for example battery manufacturing. when you need to produce type CR2032 battery, you need to list what material are used for that type, and how it's going from produce to packing. you will know the complexity where they give you a task to create for example "monthly report of that CR2032" per shift (with time range per 30 minutes), and they want you to list what are material used for that like how much gram of bobin, what time the bobin out from oven, how much electrolyte needed, and much detail. and those material can change after production is stopped. you will need recursive cte query to populate them. it's more complicated than a select satement with some join. and do you know? any brand can run CR2032, like energiz*r, panason*c, etc. and they have different item and BOM (different formula to create a CR2032(. and again, that's example is still 1 type, actually they can run multiple type :D

[@ipiptr]

maybe it's easy to do it in c# for loop, but you will end to "N + 1 query" which is a bad practice. so, can you do it in one trip sql query? I think that's what Nick wants to emphasize in this video

[@PhaaxGames]

The #1 thing I've looked for in people I've interviewed is if they're comfortable with not knowing everything but eager to learn. This person failed that 100%. You need to ask questions! You need to be curious. Solving a mystery needs clues and to find the clues you sometimes need to ask questions. :)

[@fredrikjosefsson3373]

Our best senior at work sometimes works in the project I work in if we need something really advanced for instance. He always introduce things I've never seen before, and I often ask him to go through his PR instead of me going through it myself because then he can explain all the new stuff. Great way to learn new things

[@orterves]

First and foremost in my mind when interviewing someone (and when being interviewed) is smart and gets things done, a desire to learn and grow, and humility. A good engineer will hit the ground running in the areas they are confident and learn everything they need to know - and not be afraid to ask "dumb" questions - to take on anything else

[@reginaldblue7240]

Here's my random thought: What did the job position list? There are, surprisingly, jobs out there that use .Net but do not use SQL. Your typical job, sure, but there are ones that are interacting with other kinds of resources besides large quantities of structured data. If the job position said "must be competent in performance analysis of SQL" then, yeah, he should have been better prepared. If it didn't list it, then they need to rethink their job descriptions.

[@Kotz_en]

Something similar happened to me once. It was a back-end .NET junior position that leaned a bit on web technologies/environment. But in the technical interview, I got hammered with WPF questions. The job description made no mention of WPF or anything desktop-related.

[@Jacobhay09]

I like the call out about knowing and growing your knowledge for things around/outside of the code. Getting better at writing code will come in time. Languages are always adding new things and every person/company/team is going to have an opinion on how you should write something. Always keep in mind that mangers (if they are good...) should be looking for the "How", "Why", and most impotent "I don't know but this is how I will find out". I had fellow manger tell me once "I can teach anyone how to code. But I can't teach a person how to think...". This has stuck with me for years as a manager. The key thing I look for as a manger is the person knows the "why" behind their answer. They are okay with saying "I don't know". Having the drive to say "But lets find out" and sharing/showing how they would.

[@GuidoSmeets385]

In general adding an index won't improve a SaveChanges call, it will probably decrease the performance.

[@ДенисЕгоров-ь3в]

Adding useles indexes and foreign keys can also drop performance when you search value.

[@TheRicherthanyouguy]

As someone who’s on a team where my SQL skills have needed to improve what we all learn will be need based. Learning SQL is a great skill to have for sure but we can only learn so much and we have to pick and choose accordingly

[@randombubby1]

I’m going for entry level and this was a great video! Gave me a good heads up to ensure I am solid on my terms and concepts. I’ve been using Go recently which has forced me to write SQL manually. If the poster has only used EFCore I totally get how they would get confused it really does abstract away all of the nitty gritty details

[@alanschmitt9865]

The near-term (and probably long-term) future for the field is dissolving the silos of FE/BE/DevOps, etc. Employers don’t want to pay for one of each if they can pay for one doing all three. SQL and other DB providers are complex enough to deserve their own expertise, but employers don’t necessarily want experts, they want the cheapest resources that won’t blow up production. Either way, knowing how relational databases actually work can never hurt you, if you have the time to put toward it.

[@marcotroster8247]

Haha yeah. Companies hire the cheapest fool who gets the job done 😂 Idk man. Those modern frameworks don't solve any real problem. They just obscure everything. Engineers don't seem to understand their machines anymore 🤔

[@gppsoftware]

I agree with this. For those of us who have been in the industry for 30+ years, we are used to doing the entire stack. The creation of FE/BE/DevOps/DB silos was a frustration for us because we could do all of them but were not allowed to cross boundaries to correct the errors in the different silos. The only way forward was to move up the management ladder. From a pragmatic business perspective, it is far more cost effective to have a good all-round full-stack developer familiar with your stack than it is to have separate people for each silo. My biggest concern/observation is that FE developers (particularly React) spend an awful lot of time fiddling around, writing large amounts of unnecessary self-job-creating code trying to perfect the perfect!

[@alanschmitt9865]

@@gppsoftware Honestly, I’d argue that the development paradigms within each “silo” have diverged significantly enough that they need to be their own positions to maintain quality of product; but the fact is that most employers don’t care about quality, or else the cheapest quality they can create profit from.

[@gppsoftware]

@@alanschmitt9865 For some silos like security and networking, that's possibly true, but general DB/BE/FE software development, probably not. Agreed that most organisations don't care about quality and are only interested in profits. What they don't understand is that a little more quality, using qualified people can actually create bigger profits because these people have the experience to avoid going down 'rabbit holes' and wasting time on unnecessary tasks and tech!

[@tensor5113]

@@marcotroster8247 Then code purely in assembly, or C. Show us how much you truly understand your machine. Also, I hope your interviews consist of the physics of a CPU, since we need to understand our machines

[@goaserer]

While I've encountered devs that only knew how to work with an ORM, at some point in a non-trivial application there is a point where using SQL is simply the better choice. Nobody knows everything, and education usually teaches the basics defined by SQL:92, so the main question is usually whether you are willing to learn In the end a developer has to familiarize with the components of the project. If your data is stored in an RDMS this includes know-how in SQL

[@anoftc]

SQL (and the relational way of thinking about data) is a must in all dev roles. This is also true, if the job is about a non relational/non database related task; and if sql seems unrelated to the job. Ppl can revolt and say its bad, but it is still considered a *BASIC* must-have common knowledge for almost all devs; and measuring the logic thought process of future colleagues is the easiest with some sql tasks. It is not to test the advanced skills, it is to test the level0 logical skills of an applicant.

[@mohammadjaber3898]

Yep my friend This is a good subject to present Also We need The developers to understand that index is not the magical spill to your bad queries

[@BW022]

I consider SQL like a number of technologies which technically aren't needed but you probably don't understand the basics if they haven't used it. I started programming in the late 80s and today I see so many folks tripping over things because they are used to levels of abstraction over the hood. I've seen junior devs have performance issues in JS because they don't understand memory allocation as they've never used C, I've seen analysts struggle over floating point compares because they don't understand how computers handle floating point, and I've seen folks not understanding indexes because they've never used SQL on something which honestly required indexes.

[@the-niker]

Yes, this is why I always use the database-first approach. Know your SQL, optimize your types, write those indexes, see those execution plans, write your cover indexes. Views and stored procedures can also make certain tasks trivial (and much more performant) compared to code-first approach.

[@fredrikjosefsson3373]

The project I am working on was inherited from another company and there were no indexes, not even real foreign keys (which in ef core code first, you get those indexes for free), everything was nullable and nvarchar(max) (except of course ints, and dates, and bits) I have worked with this project for 2 years (out of 2 1/2 years experience) and improving performance has been like my main thing I have done during these 2 years. It's actually what I think is the most fun together with refactoring bad code. I still think its hard to figure out what indexes should be added because it is very hard to read an execution plan, but the greatest part of this job is to learn new things and keep improving. Never used database-first so I don't have any experience with it, but can understand that it gives you a better understanding of SQL My project leader has worked as a software engineer but now is just a project leader and havent written code in ages, but he is still super at SQL, so if i need help with SQL he will write a great performant query

[@dirkschannel5817]

@@the-niker I agree. Despite all code first talk, I very much prefer database first. It always served me better in the long run. Code first falls apart when the project grows beyond the size of the usual demos

[@the-niker]

@@fredrikjosefsson3373 Try Plan Explorer if you want to better understand SQL execution plans, it gives you greater insights than the SSMS basic view.

[@robrider838]

@@fredrikjosefsson3373 And just think what you did in 2 years, can be done in 2 weeks now with AI tools.

[@fusedqyou]

I have been using EF for everything, only recently figuring out the magic of views, SPs and triggers. Absolutely amazing how much you can do.

[@calvinwilson3617]

Not knowing sql or another db language and trying to work with a database is like trying to ask a non programmer to use ai to generate code. You can do it but they may fundamentally misunderstand what is occurring. An interview question isn't about getting a specific answer, its about understanding the person answering the question. There is a million ways to write a segment of code. How does someone write their code? Do they understand what their code does and why they did it the way they did, or are they just repeating memorized information?

[@ivozubovic3848]

In my last ~7 years of work experience, I had to write a single simple select query on an existing database. The relevance of sql in my career was practically zero. Knowing x86 assembler, linear algebra and graphics programming was vital however (not only in game dev), so it really depends on what kind of software engineering you are doing

[@rcherrycoke7322]

This is the right answer! You need zero Sql knowledge of your’re doing game dev, hardware dev, document db dev, AI , etc etc

[@brandon-22]

@@rcherrycoke7322 yeah I listened recently to Casey Muratori and there was another camp too telling there is no need any framework or docker strong knowledge because those tools are short-lived and reading assembly is what really important. .NET dev should probably know at least relational database theory though..

[@paulkoopmans4620]

I agree with the need for SQL. If you would be analyzing any slow database access, regardless of the framework you are using, you need to be able to get the generated SQL and look at it. I've had it countless of times that whatever EF is generating is problematic. Sometimes reordering the method calls is all it takes to get a better performing query. Other times custom query's is the only way to go. There are also many other things I have been involved in and EF or Dapper is not the solution. Indeed things like indexing issues, redesign (like split tables), custom one off reports that a manager or department needs. The list goes on and on.

[@HarleyPebley]

It all depends on the domain you're working in. In my 40+ years of development, I've never had to learn much beyond "select * from table". Anything more advanced and I just do a web search on an ad hoc basis. I know enough to read the results and apply them as needed but I'd never be able to come up with them on my own off the top of my head. The domains I've worked in since SQL has become mainstream have had very little need for SQL. Early in my career, I worked in domains where it would have been used if it existed, but it hadn't gained widespread adoption at that point.

[@bogella2225]

When I was interviewing people, I would always take the less technical person who could ask questions when they got stuck compared to the more technically sound person who could/would not ask questions.

[@CricketThomas]

Printing the sql, one step up: OPEN the query profiler. Open query plan and it will tell you what’s wrong with it

[@raggardy]

Cheers for your videos, Nick. Will there be an upcoming SQL course on Dometrain ? All the other courses I've taken on there are mustard, mate 👌

[@batuhanaydn4592]

CMU's database lessons on KZbin helped me a lot to understand how it works under the hood.

[@vitalyl1327]

Been in the industry for over 30 years. Used SQL a couple of times, last time over 20 years ago. So no, software engineers do not "need" SQL. Some do, depending on their domain.

[@jonathanschafer4111]

While I'm not a EF fan, I know many people like it. But, I would say as a DEV, it's like should I learn HTML/CSS/JS first or just learn React, and the answer should always be learn HTML/CSS/JS first, then React (or Angular, etc). Same for SQL .Learn SQL first, including building tables, indexing strategies, parameters, stored procedures, etc. Once you have a good understanding of the base technology, then use EF if you want. That way, if anything goes awry with your queries, you'll have a solid fundamental understand of how to attack the problem. Printing an EF query doesn't help if you don't understand SQL. Even running it through Profiler or generating query plans isn't helpful if you don't know what you're looking at. Do you understand an index scan vs an index seek? Unless you are a FE only engineer, you should absolutely know SQL and know it well. I like DBAs for monitoring the DB, but I've never had to rely on one to fix my SQL, table designs, indexing, or stored procedures.

[@CLeovison]

Hi Nick, Can you make a video on how to make our own analyzer? Thank you so much

[@DevMeloy]

The wider you try and spread your knowledge base, the less you'll know about each layer. I definitely try and keep a base level of knowledge on all layers, but try and focus on a few areas of expertise.

[@regestea]

So , why i don't see any SQL course in dometrain ?

[@saberint]

ok I am going to fly in the face of all of this. I actually think the most important part of any interview is making the interview team see you as part of their team. Normally, a job will have between 5-50(!) people people that interview that can do the job so as long as you can do the job you are going to be fine. Now the hard bit is making links between you and the interview panel. Make eye contact, make jokes (remember these people have been doing interviews all day), make connections in some way if you can. Ask about company sport teams (they always love this)... basically, make yourself likeable. As for the code... well I am old fashioned. Dump it in a stored procedure and be done with it😂

[@catalystcorp]

Depends on the interview. I'm a freelancer now, but when I worked office jobs it wasn't unusual to have two interviews - one technical, like Nick is talking about, and one "cultural" or "team fit", like you're talking about.

[@saberint]

@@catalystcorp oh I have never had 2 interviews. I have had 5 people on a panel and the interview taking over 2 hours though :/ I guess the technical one means you have to carefully read the room before making a joke or trying to be friendly. Thanks for your input 🍻

[@brandon-22]

@@saberint idk looks weird going off topic themes when time is already short. Just geeking out about brought technical topics resulted in good offer to interview ratio for me. And I always had mistakes (sometimes very silly) just as Nick mentioned it's the overall view. I hate when SWE gets hired through talking his way in and then you find he's more like intern level but without rapid learning.

[@saberint]

@ oh you definitely need to be able to do the job. I have just interviewed so many people over the years that were very smart but I couldn’t work out how to fit them into the existing team. So, give me a reason beyond what that piece of paper says about you

[@bartlomiejuminski]

Using raw SQL or stored procedures requires manually updating all related queries and procedures whenever an entity changes. In contrast, with EF Core, entity changes are made in a single file, streamlining the update process. This makes ORM a more efficient and maintainable approach.

[@theprimecoder4981]

I used entity framework alot but I made sure to sharpen my SQL knowledge...it's aloways good to upskill on these

[@sunny7268]

of course, even if you use other DBS, as SQL is a starting point for DBS in general, many do not know what is ACID, because Mongo does it really poorly, I say it as developer who use only no SQL for last 5 years.

[@xnetc9]

SQL isn't required where I work because they use EF. Don't need html/js/css either because we use blazor.

[@RiwenX]

I landed my job without knowing SQL. I learned it on the job. After 7 years later, I can finally recognize how lucky I was to get the job in the first place, lol. Yes, SQL is a must.

[@rwj_dk]

IMHO: The very first question should be 'Please define slow' (Are we talking minutes/seconds/miliseconds) and when it come to the database: How big is it (Megabytes or Terabytes?, How many Table/Records in total and How many returned from the API call)... That way we know highlevel what we are dealing with instead of just throwing our "tech" at it head first... After that profiling to know if slowness lies in pure code or SQL

[@Wfmike]

Its not about db knowledge but the attitude. "I don't know" is can be easily interpreted as I don't really care in this circumstances

[@distantcam]

Senior engineers know when to say "I don't know" and look for help. The solution to the problem wasn't what they were looking for.

[@antonmartyniuk]

Dometrain needs Dapper course

[@tsopanaras]

And some SQL / Databases courses as well

[@matejskerjanc7703]

also Dapr would be appreciated :)

[@BTimelessC]

If I remember he does use dapper in some of the courses about API's for example. A full course on Dapper I would say might be too much

[@gppsoftware]

Dapper was the latest fad in 2010 when Microsoft had Linq2SQL and still hadn't got their act together with EF, but today, no-one uses Dapper. It is old tech. Your client won't thank you for imposing instant tech-debt on them with Dapper!

[@dirkschannel5817]

I agree. SQL knowledge is key. I run a small software company and I consider SQL as a requirement. I learned it the hard way... However lack of SQL knowledge is quite common these days. Maybe, it's because I am 42 and somehow a dinosaur. I treat ORMs like calculators in math - great tools, but use them when you're able to it by hand.

[@saberint]

eek I am past 50, still hand code all my SQL... oh look at that pretty flaming thing in the sky!🌠

[@dirkschannel5817]

@@saberint I do so too. It feels natural to write all my SQL.

[@Krapvag]

I always tell people to learn SQL, it went hand in hand with code during my junior career so I guess that's why interviewers expect people to have some understanding of it. As they should really, it's important to know

[@GackFinder]

hello fellow dinosaur

[@ian2neko]

Maintaining a LOB application, 60% of my time spent SQL related. And of course not counting time spent on user or management meetings LOL. DB Admin, table and index design, troubleshooting, ETL to report DBs, PowerBI, SSIS, SSAS, Azure SQL..... etc

[@GackFinder]

Completely agree. Specifically, software engineers need to understand set-based operations.

[@7th_CAV_Trooper]

select * from ThingsYouMustKnow where Career = 'DEVELOPER'

[@yorkaturr]

Just use Dapper so you see what's happening. SQL is self-documenting anyway. The only reason you'd want to abstract SQL is if developers are not familiar with it.

[@mattymattffs]

I don't know if I would say that you have to know sql, but I would say that you have to have a basic understanding. When I see people write code that makes a ton of calls to a database even when they weren't necessarily needed that's a big red flag. When I see people not consider the impact of their query, that's a pretty big red flag and this is not uncommon. When I train my Juniors I always try to put it into the perspective of the database. The majority of our slowdowns is the database. It's really hard to get that across to someone when they don't even have a fundamental understanding of SQL

[@krajekdev]

SQL is a must for people anywhere near software development. Lucklily this is one of the best investments you can make since: a) it is relatively easy, once you get the proper mental model of sets b) does not change drastically over years or even decade (like js libraries for example)

[@netssrmrz]

From my experience, most devs use ORMs (eg. EF/LINQ) to avoid SQL. If you want to be considered a serious fullstack or backend dev, you need to know SQL and some RDBMS design and admin. As others have mentioned, this should've been covered at uni. It's not that hard. At least you'll learn what ORMs are really trying to solve.

[@edgars2113]

What a great title to read on the second day of 2025 😅

[@robrider838]

SQL is simple to develop and understand since I have Cursor/Claude.

[@Denominus]

I expect people to have RDMS knowledge relative to their seniority. For a senior (and up), they MUST know how to do database design, queries and indexes that is performant, as well as perf optimization/debugging. I don’t expect DBA knowledge (clustering, zero/minimal downtime upgrades, replication etc.), but it won’t hurt! Devs with sharding knowledge and experience is also quite rare to come by. I do think it’s excellent advice to look beyond your code bubble, getting better at the skills for things outside the code are in high demand and give you a much bigger picture.

[@brandon-22]

at this level shouldn't person reach maturity and just understand weak points and use services that takes care of you of this already (looking at cloud providers)? And if traffic really matters then tuning with specific database choice, ie managed nosql

[@Denominus]

@ No managed database just takes care of this for you, nor does managed NOSQL (ie DynamoDB/Mongo). Not understanding these fundamentals is a sure fire way to get a huge database bill AND poor performance. Do people commonly think this? That managed databases just magically take care of this?

[@brandon-22]

@@Denominus I don't get your point since you're not running anything extra than backups on dynamo/aurora and businesses are building their solutions using those dbs. Whole premise is not doing it yourself AND not being able to

[@Denominus]

@@brandon-22 First, my entire point was NOT around DB administration (though having those skills is a bonus), but about design and usage that is performant. I expect seniors to be able to do RDB designs, queries and indexes that are performant and not wasteful. Second, managed RDBS mostly take care of the *low* level administration, but not ALL administration. Postgres Aurora Serverless V2 for example, you still need to worry about vacuuming, the xmin horizon, replication slot lag, free xids, disk performance etc. etc. We have extensive monitoring on our Aurora instances to stay on top of these things. Dynamo is much more administration light, with the trade off that it puts a lot more pressure on you to do a correct upfront design based on your query requirements. Get it wrong, your billing explodes and your performance tanks (hot partitions and scans instead of queries) or you run into races you weren't expecting to deal with with GSIs.

[@F1nalspace]

In the last 10 years i haven't touched SQL at all or even databases for that matter. Our data is file based stored in special formats that supports partially streaming, so there is no need for any databases. But we use hashtables and special collections to sort and find items based on unique string combinations. Many years before that i was using SQLite a lot and was happy that my SQL skills from my very early days was still useful. But its not true that every developer needs to know sql. It may benefit them, but its not required - depending on the job. Of course if you go full API web development stuff, you have to learn that obviously.

[@robert8930]

suggestions on where to improve my sql knowledge?

[@simongeering]

The books on SQL server programming and querying by Itzik Ben-Gan are excellent. Even though they relate to older versions of SQL server, almost everything there is still relevant today as SQL is mostly additive building upon what came before.

[@tarquin161234]

The Microsoft learning pathways are good

[@catalystcorp]

Since this is a Microsoft-focused channel, I want to specifically mention learning Postgres which is very similar to MS SQL but also subtly different in many ways that will matter. Postgres is open source and much more popular than MS SQL outside of the .NET world.

[@brandon-22]

@@catalystcorp what about Azure SQL? Seems T-SQL dialect for cheap on Azure cloud

[@happy_burger]

As someone who has to interview .NET engineers, but I suck at it, it would be cool to have a Dometrain course for this topic :)

[@gppsoftware]

Not wishing to be disrespectful, but if you think you suck at interviewing, it suggests to me that you may not be very good at it and you shouldn't be doing it. The reason why so many companies get the wrong hires is because they have the wrong people doing the hiring which in turn, is a management problem.

[@AmateurSpecialist]

I'm a senior dev, and while I do EF mostly, I do write SQL, but darned if I have to google the proper syntax for anything other than a SELECT.

[@marcotroster8247]

Don't optimize without a benchmark and acceptance criteria. Ask who raised the performance issue and in which context. Ask if their pipeline runs stress tests or if they have any documented acceptance criteria. You need to communicate to figure out what's going on. Only then look at the code.

[@chudchadanstud]

You need to know SQL but you don't need to *KNOW* SQL. Given the docs you should be able to navigate your way around it.

[@br3nto]

0:30 in uni, devs are taught set theory and relational algebra, as well as database design, database architecture, etc etc. I think all devs should know this stuff. I’ve also been writing sql queries and designing dbs since starting my professional career. Every app needs to persist data… so we as devs need to know the intricacies of that from the start.

[@Tresorthas]

Most devs here didn't even go to university.

[@br3nto]

@ fair enough. I guess they would need to do the equivalent self learning if they want to keep pace effectively.

[@johanngerell]

Oh sweet summer child... :) ... "not all Software Engineers". As a SWE of 25 years, the area I've been in hasn't touched anything near SQL for 24 of those years. If I got a SQL question in an interview I would loudly question if I accidentally went to the wrong interview room.

[@orterves]

Knowing sql well isn't just pragmatic and highly useful, like functional programming it will give you a new way to think about data and programming generally Also crucial is IAC, containerisation and telemetry

[@seesharp81321]

All these interviews are biased. If you do interviews like this you need to lock in on what's expected. So ask as many questions as you need. Make it hard for them as well. On a personal note I probably would have asked for code that the senior dev had written himself and would formulated an opinion on that, but that's me 😜

[@TheOnlyDominik]

No, not necessarily!

[@davidjackson148]

Yes. You absolutely DO NEED SQL. You don't need to be a DBA or anything that level. But you might have an issue where you need to dig around the database. As a Dev Manager Devs without some SQL are no use to me at all. A lot of projects I've worked on over the years, the database is already there. Just knowing Linq and EF is not enough.

[@ByteBeacon9660]

I wanna cry

Seen to much wrong assumptions from people only using EF/EFCore.

[@ErnaSolbergXXX]

Deep db knowledge should be ranked as much more important than knowing the the billions of packages you can use to «not reinvent the weel»

[@Brymcon]

❤ entity is not SQL.

[@zoltanzorgo]

I agree. One should know even deeper than just the standard SQL. At least how indexes work, but I think you need to know the exact flavor you are developing to. EF can hide only so much. There is also a limit on how expressive linq can be: even something as a left join can be a headache, not to speak about many of them. CTEs, subqueries are not really a thing there at all. Not speaking about lock hints, and other low level things.

[@aluced]

Just add caching ;)

[@magisteriumemporium1411]

Ahhh yes... time to screw over junior who are already screwed over either way :D If you need a junior write/understand a performance critical SQL then that's a senior dev problem. There is a good reason we use ORMs

[@przemysawukawski4741]

Important thing - try to avoid OR in the SQL queries as much as possible. Turn them into UNION's or write conditional where statements in LINQ. This is one of the most frequent issue related to performance of a queries. Making an OR between columns from different tables will force the full scan of indexes and when the table have millions of rows, you are basically f... up.

[@SuperLabeled]

90% of an interview is behavioral and situational. We can teach coding, it's harder to teach relationships :)

[@weicco]

I beg to differ. I know SQL very well but that will not give me job. Why? Everyone is using Entity Framework. SQL is only needed when EF produces so idiotic SQL that the system starts to really suffer. The first solution is always throwing more money to it (downside of cloud services - you can always throw more money in). Secondary is actually fixing the db, but at this point it has become unfixably usually. There is so much data that e.g. creating new indexes requires taking the whole system down for maintenance. Been there, done that, and hate it.

[@andrewshirley9240]

I wish everyone used EF. My last couple of jobs used monstrosities of stored procedures, or even worse, a hard-coded "base query" with clunky query builder API slapped over it. I even have tried explicitly looking for EF in job listings, but it seems like most companies interested in modernizing are going full hype-oriented programming and going to NoSQL disasters. There's no winning lol

[@weicco]

People say you should use EF and stay away from views and stored procs because "we do not want business logic in database." I love the empty stare after I reply "ok, I'll start removing primary keys and foreign key restrictions immediately." 🤣 But yeah, you can make things really confusing with heavy use of store procs.

[@fusedqyou]

How would you write SQL when the data starts to not be strongly typed? For example, I have an API that seamlessly transfers data into a table and I want it to be future proof when more columns are added without updating internal models. How do you suggest I do this without writing raw SQL?

[@weicco]

I'm not quite following but there have been cases where EF has come up with suboptimal queries, especially when query filters were enabled. I optimized those by using FromSql. Sometimes tabletti schema can become suboptimal when devs don't understand how tables are beign created in db (usually tables are awfully fat). Many times there is not a single index, not even unique constraints where they would be needed. These problems arise from not understanding sql and databases in general, and ORMs making it so very easy to shoot yourself in foot.

[@rreiter]

Retired now, but when I was using it, EF produced a lot of idiotic SQL. As we modernized an "old" application we also tried to make it less dependent on SQL coders by replacing stored procedures. Unfortunately in many cases corresponding linq and performance became so abominable we didn't. By the way, does EFCore in C# give a developer access to what happens during SqlServer database triggers yet? Just asking.

[@joelneto90]

Hi Nick, love your videos... but, sorry be the person that corrects people, I dont do this... but I assume english is not your original language (mine either) but the title should be "MUST KNOW SQL", not "MUST 'TO' KNOW". 😅

[@nickchapsas]

I changed the title and I forgot to change the to 😂😂

[@joelneto90]

@@nickchapsas I LOVE your videos, and like you, I am also very into performance of code and patterns. I found your content veeery informative and professional. So that is why I noticed the title... I thought: no, I will tell him about it. I will ensure his quality on every instance. 😅

[@Revin2402]

What a clickbait title. There are so many different software engineer roles out there which don't need any SQL knowledge. In all my years I never got asked about SQL and I only needed it here and there.

[@jezuschrystus4839]

database is part of the daily work of a backend developer. So you can't be a backend developer without having database knowledge. Just as the frontend needs css

[@gabrielnzete8913]

You must know it and know it very well.... because if your code must be clean you must shift some of it to the DB 😊.

[@adambickford8720]

If you don't know SQL you are a mid-level dev on your best day, and this is assuming you're some kind of UI or cloud savant. If you can get by w/o sql, you are in a bubble and waiting to die.

[@DevMeloy]

Most devs are in the category of knowing enough SQL to be dangerous. Sure, we should all know how to read at least moderately complex queries but companies who rely on full stack developers will almost always be fighting performance issues due to poor SQL optimization.

[@brandon-22]

know sql to do what? only thing might be making proper up/down migrations that doesn't wipe out data

[@adambickford8720]

@@brandon-22 you don't even know what you don't know.

[@brandon-22]

@@adambickford8720 i'm ex dba but whatever

[@DevMeloy]

@brandon-22 all depends where you work my dude. I've worked at places where we all wrote SQL, used ORM's to having SQL dev's.

[@RattaTa-t6p]

who uses sql in 2024 lol

[@catalystcorp]

Hundreds of thousands of businesses use it. Not only that, almost every query language on earth is based on SQL.

[@gppsoftware]

Every business that cares about responsible corporate management, integrity and quality of their data. Every business that recognises that using a no-SQL solution as an RDBMS is a receipe for corrupt data. Every IT department that recognises its responsibility to the business and its shareholders.

[@mavisbeeswax8136]

If you don't know databases, you really have no right to be working in IT.

[@gppsoftware]

Not necessarily, but you really are just a junior developer.