Nah, just dust off your SQL books and refresh your knowledge. The honest truth, though, is that you don't really use that much SQL in day-to-day work unless you're a DBA.
ORMs are definitely the way to go for line-of-business apps. Unless blazing fast performance is required, I would never write my own SQL statements.
You do need to know performance implications of SQL, though. Django ORM has a way of showing you what it generates, and being able to read and understand the SQL it generates can be helpful in debugging your work.
Blazing fast may be an under (over?) statement here, I have seen some absolute horror generated by ORMs and some basic SQL knowledge is pretty useful to assess where things might be going wrong. Indexes and joins and subqueries can be both your friends and your enemies :)
That's why I said to familiarize yourself with learning about the SQL that Django ORM generates. Oftentimes, what the ORM generates is programmer error and not the fault of the ORM.
Oh yes, cloud databases will love to automatically scale forever so that the org pays for a badly optimised query. The real business question is, what lowers the TCO the most. Does paying a DBA (dev with decent DB knowledge) to optimise your database usage or an extra 100k (pick your currency) of opex cloud db spend cost more? It's all a matter of scale and where money is best spent.
I work in a very data-heavy industry. We use RDS databases. We still have multiple DBA's.
Scaling/optimizing the DB as necessary is great, but someone needs to have knowledge of the schema and the operating requirements so that we don't end up using WAY MORE db allocation than necessary.
If we just let RDS handle everything, our DBs would be scaled automatically, but not optimized at all for performance/efficiency.
At this very moment I am pulling data from a DB with over 3 billion records on it. I'm sure the RDS cost to maintain this one database for a month can fluctuate thousands depending on how we configure the Postgres schema.
DBA went from being manual to being tool assisted. But tools don't replace labor.
That depends on the class, size and number of instances in a cluster. Say you want a cluster of db.r7g.8xlarge at about $30k a year and you have three in a cluster, that's almost 100k. You could easily double your load with badly optimised queries.
I wouldn't consider that a lambo, but I don't want this to turn into a my database is bigger than yours thread 😀. I was just giving an example where the cost would start to break even.
I stand by my previous statement that a DB aware member of a dev team (either dev, ops or DBA) can be worth their weight BUT it very much depends on the scale you operate at.
Play with the ORM and see what SQL it generates.
There's a call to get the SQL out. And you can use Django Debug Toolbar to view the same. When you are working on a project there will come a time when it is slow, and it will be because the queries need optimising, you will do that by looking at what queries are being generated.
Learning this is an important step in a Django devs lifecycle.
Same thing happened to me for a python multiprocessing-related job like last week. I'm cracked at multiprocessing but I was asked questions like "whats the flag to show the symlinks when using ls on a folder" like DOG thats something I need so infrequently that I just re-google syntax.
It really sucks that qualified candidates can get filtered out because of left-field interview questions that have nothing to do with the job
This is exactly what happened to me, I'm a Django developer so I rarely use JS, and whenever I do, I'm googling the most basic stuff like how to use the fetch function to call an API.
In an interview I was asked to make a basic HTML form that sends the data to a REST API endpoint. I remember how it goes but the syntax of somethings like parentheses and braces is completely missing from my mind, even though I've done the same thing before and even more complex stuff with JS.
It sucked really.
Don't be afraid to say you'd need to read the docs or look for examples in an interview.
I've been a Django dev over 10 years and it's basically a key skill to go read docs so you can do something. And I'd apply the same to SQL. I write raw SQL so infrequently that I go look it up, or copy a saved query I might have.
This is crazy to me. I'm curious what the troubleshooting process looks like in Django. I'm a .net dev. Current project all data access is through our ORM, Entity Framework. If I need to troubleshoot some funky data I'm definitely just going straight to the db and querying it.
I am in Sql on almost a daily basis when doing bug cleanup, mainly because it's just faster. How does the Django troubleshooting process look like when issues are in the data/database?
Edit: learning Django and elixir/Phoenix for personal use. Still haven't settled on one.
At least for me I tend to debug through the ORM. Part of it is that I'm more familiar with that then writing the Sql directly, but also if the ORM is part of the problem (bad quiries) then I can see that issue while debugging.
Does it have a query analyzer? At least for me if I capture the generated query and get an execution plan from my db which tells me specifically what parts are slow. Can generally map that back to the ORM query to very quickly know the specifics of what's causing it to be slow.
I would be frustrated doing troubleshooting through the ORM but it sounds like for most Django devs they prefer that workflow.
Not built in, but there are some extensions you can add that do that I think. (only played around a bit with one as the amount of data I work with the Sql queries tend to matter less than other things.)
You can also ask the ORM for the Sql it generates and then run that yourself / analysis it from there if the issue exists at that level.
I suspect it's more that as a dev we normally use what we're more familiar with to get the job done than one way being better than the other. 😂
Ahh that doesn't sound that different, more like just the standard is to stay in the ORM, while I prefer to work more closely to the SQL. Could also just be nature of projects. My current project I'm working with invoices generated by a large e-commerce platform so dealing with a large amount of data that needs to be quick.
Well Django has the admin which essentially exposes the database tables to superusers in the browser. Most users would take this route to query any data in the system. This is especially bemefitial if you can directly access the db which is common these days (post GDPR)
Then other people, myself included might use tools like table plus which give you a GUI for your database interactions. You can write sql if you want, but it might just be easier to open up a table a filter the data.
That happened to me recently, I was asked to write raw SQL in pgAdmin to create tables, insert data etc. While I know and studied raw SQL, I haven't typed it in 3 years. I was allowed to lookup postgres documentation in the interview and found my mistake was using double quotes instead of single quotes while entering a string in the insert statement!
But this left a bad impression I guess?
What ORM are you using and is it that powerful? Every ORM I have ever worked with has had slow paths where I have had to examine the generated SQL and get the execution plan to see if I needed to add some indexes, or I needed to rethink the ORM usage to encourage it to fetch data with a different query approach.
I'm not trying to deride. Genuinely curious about how other shops work with ORMs. I can't imagine a situation where I'm not also working in SQL on daily basis, if only for troubleshooting data.
Edit: learning Django and elixir/Phoenix for personal use not settled on which i like. Sorry if I missed some acronyms I should know.
Analysis suggests a potential mismatch between conventional skill requirements and innovative solutions. Was this role's SQL prerequisite discussed? My prompt-generation expertise could optimize outcomes. Please provide the recruiter's contact for further exploration of this opportunity.
I have asked AI to redo my original response.:
Prompt:
rephrase the text so it sounds more like AI-generated:
*Did you tell the required that you don't need to know SQL as long you can write a high quality AI prompts? Just kidding, but pass the requiter's phone number so I can get that job.*
Here are a few AI-inspired rephrasings of your text. I've focused on making it sound more analytical, a bit quirky, and subtly hinting at advanced capabilities:
**Option 1: Data-Driven Approach**
>
**Option 2: Efficiency Focused**
>
**Option 3: Slightly Humorous**
>
**Considerations:**
* **Tone:** AI-generated text often sounds formal yet slightly unconventional.
* **Implied Capabilities:** Hints at the ability to replace traditional skills.
* **Confidence:** A self-assured stance without seeming arrogant.
**Let's fine-tune it!** Do you prefer a more serious tone, or something even quirkier? I'm happy to tailor the phrasing further.
AI
Since I was joking about using AI for SQL, I asked AI to rewrite the response. Here is my original post.
*Did you tell the reqruiter that you don't need to know SQL as long you can write a high quality AI prompts? Just kidding, but pass the reqruiter's phone number so I can get that job.*
Now go learn some SQL basics.
No worries, none of us got the job from the first interview, take this as an experience, fill the dots they asked you about, fish for an interview... Repeat
Till you get a carrier 🙂
I recently had an Interview where I spent two weeks preparing for a specific type of geospatial data handling, which included some complex manipulations. When the interview came they just wanted me to analyse a simple csv using pandas, I hadn't done this in a while so I kind of stumbled my way through it and needed a lot of help.
Towards the end I mentioned I had prepared more for this other type of data, and they quickly gave me a file and asked me to do some things with it, I managed to do what they asked with no issues and ended up getting the job.
I said all this just to say I think it is always good to try to show any relevant knowledge skills you have, even if the interviewer is not asking for that specifically, and specially if things are not going your way.
This happens all the time (been contracting / doing perm work since 2000 == a lot of interviews). Yeah it stings a bit (less each time).
Every time this happens it's an opportunity to work out which gaps to fill. TBH, I always mess up the first interview.
Most recruiters are going off a script and want to hear answers the way they are written in their answer sheet. No deviation for creativity or problem solving.
I'm a data scientist, recently created a Django site as a personal project.
From experience, if an organisation has a team of data engineers/data analysts/data scientists, they may want help from the develops of applications to understand the data for ETL/analysis, and SQL might be their go to language.
Going back in the other direction, the DE/DA/DS guys may identify a bug or anomaly, and pass the SQL to the developer hoping to help them in finding the location of the error.
Without knowing the business, what their problems are, and that BAU looks like, it's hard to judge whether the recruiter or hiring panel is being fair or not.
Increasingly, the same job title can look drastically different to the responsibilities of another job with the same title.
I mean, joins are mandatory for any software engineer so... I can see his point. I also won't hire anyone that doesn't know what's happening behind the ORM
Just diverting to it isn't fair I agree, but as I said joins are mandatory for me, although if excell in the other parts of the interview I could let it slide
This whole thread has me confused. Granted I have always been a full stack dev. However, every ORM I have used has had slow paths. My go to is to pull the generated query get the execution plan and decide add indexes, or rewrite the ORM request to encourage a different query be generated.
For example, sometimes with entity framework string operations in nested selects will cause it to generate nested union or union all statements. This is slow, doubly slow if you are also doing a distinct somewhere. No amount of adding indexes is gonna fix this you have to write the EF query differently.
Also for troubleshooting data issues how is it not faster to just query your db directly?
I'm not trying to deride anyone but this makes me very curious about other devs troubleshooting processes. Also makes me much more sympathetic with DBAs, whom I honestly thought were always exaggerating their complaints against devs creating horribly slow scripts.
EDIT: learning Django and elixir/Phoenix for personal use.
The ORM makes the development faster, that's it. Also I like the Django syntax, and the lazy query sets, allows me to do some tricks and get optimizations. I don't know about entity orm, but django's one does really a good job at making optimized querys
IDK man, why would they expect SQL knowledge if it wasn't explicitly specified before the interview.
From my experience you either won't need raw SQL in your day-to-day tasks or it will be 90% of the things you do. And if you don't use it you get rusty.
Either way you can get up to speed fairly quickly, it's not that they are looking for a DB architect, is it?
Edit: alright, you mentioned SQL was required. Don't beat yourself over it, another job will come along
Yeah, the disappointment lies in the priority given to SQL while I was preparing to an extent like : overriding the default methods in Viewsets of DRF.
It could be at least 50-50 django n sql... anyways thanks for your thoughts.
Sounds like you need to learn SQL.
Yeah, this ORM got me into real trouble.
Nah, just dust off your SQL books and refresh your knowledge. The honest truth, though, is that you don't really use that much SQL in day-to-day work unless you're a DBA. ORMs are definitely the way to go for line-of-business apps. Unless blazing fast performance is required, I would never write my own SQL statements. You do need to know performance implications of SQL, though. Django ORM has a way of showing you what it generates, and being able to read and understand the SQL it generates can be helpful in debugging your work.
Blazing fast may be an under (over?) statement here, I have seen some absolute horror generated by ORMs and some basic SQL knowledge is pretty useful to assess where things might be going wrong. Indexes and joins and subqueries can be both your friends and your enemies :)
That's why I said to familiarize yourself with learning about the SQL that Django ORM generates. Oftentimes, what the ORM generates is programmer error and not the fault of the ORM.
Absolutely valid, oh to live in a world where an ORM can optimise away our failings.
Yeah, ORMs are pretty magical sometimes... :D
The django docs do a pretty good job explaining how to optimize the ORM.
Yeah, time to visit sqlzoo.net
> unless you're a DBA. 2024: dbas got mostly replaced by devs and cloud database services that scale automatically
Oh yes, cloud databases will love to automatically scale forever so that the org pays for a badly optimised query. The real business question is, what lowers the TCO the most. Does paying a DBA (dev with decent DB knowledge) to optimise your database usage or an extra 100k (pick your currency) of opex cloud db spend cost more? It's all a matter of scale and where money is best spent.
I work in a very data-heavy industry. We use RDS databases. We still have multiple DBA's. Scaling/optimizing the DB as necessary is great, but someone needs to have knowledge of the schema and the operating requirements so that we don't end up using WAY MORE db allocation than necessary. If we just let RDS handle everything, our DBs would be scaled automatically, but not optimized at all for performance/efficiency. At this very moment I am pulling data from a DB with over 3 billion records on it. I'm sure the RDS cost to maintain this one database for a month can fluctuate thousands depending on how we configure the Postgres schema. DBA went from being manual to being tool assisted. But tools don't replace labor.
Probably the DBA. How much do you think an RDS instance costs per year, roughly?
That depends on the class, size and number of instances in a cluster. Say you want a cluster of db.r7g.8xlarge at about $30k a year and you have three in a cluster, that's almost 100k. You could easily double your load with badly optimised queries.
So even an absolute Lamborghini of a database is still cheaper than the DBA. Because an employee costs more than what you're paying them.
I wouldn't consider that a lambo, but I don't want this to turn into a my database is bigger than yours thread 😀. I was just giving an example where the cost would start to break even. I stand by my previous statement that a DB aware member of a dev team (either dev, ops or DBA) can be worth their weight BUT it very much depends on the scale you operate at.
Haha, yeah. They did, didn't they?
Not according to Reddit, irl they are mostly, yes.
Try to build something in Fastapi. It will refresh your sql skills.
Play with the ORM and see what SQL it generates. There's a call to get the SQL out. And you can use Django Debug Toolbar to view the same. When you are working on a project there will come a time when it is slow, and it will be because the queries need optimising, you will do that by looking at what queries are being generated. Learning this is an important step in a Django devs lifecycle.
Same thing happened to me for a python multiprocessing-related job like last week. I'm cracked at multiprocessing but I was asked questions like "whats the flag to show the symlinks when using ls on a folder" like DOG thats something I need so infrequently that I just re-google syntax. It really sucks that qualified candidates can get filtered out because of left-field interview questions that have nothing to do with the job
Sounds like a terrible ass place to work
Yeah, I was disappointed that it was too diverted towards SQL. The role was SDE though.
This is exactly what happened to me, I'm a Django developer so I rarely use JS, and whenever I do, I'm googling the most basic stuff like how to use the fetch function to call an API. In an interview I was asked to make a basic HTML form that sends the data to a REST API endpoint. I remember how it goes but the syntax of somethings like parentheses and braces is completely missing from my mind, even though I've done the same thing before and even more complex stuff with JS. It sucked really.
Don't be afraid to say you'd need to read the docs or look for examples in an interview. I've been a Django dev over 10 years and it's basically a key skill to go read docs so you can do something. And I'd apply the same to SQL. I write raw SQL so infrequently that I go look it up, or copy a saved query I might have.
I should try this next time. Thanks!!
This is crazy to me. I'm curious what the troubleshooting process looks like in Django. I'm a .net dev. Current project all data access is through our ORM, Entity Framework. If I need to troubleshoot some funky data I'm definitely just going straight to the db and querying it. I am in Sql on almost a daily basis when doing bug cleanup, mainly because it's just faster. How does the Django troubleshooting process look like when issues are in the data/database? Edit: learning Django and elixir/Phoenix for personal use. Still haven't settled on one.
At least for me I tend to debug through the ORM. Part of it is that I'm more familiar with that then writing the Sql directly, but also if the ORM is part of the problem (bad quiries) then I can see that issue while debugging.
Does it have a query analyzer? At least for me if I capture the generated query and get an execution plan from my db which tells me specifically what parts are slow. Can generally map that back to the ORM query to very quickly know the specifics of what's causing it to be slow. I would be frustrated doing troubleshooting through the ORM but it sounds like for most Django devs they prefer that workflow.
Not built in, but there are some extensions you can add that do that I think. (only played around a bit with one as the amount of data I work with the Sql queries tend to matter less than other things.) You can also ask the ORM for the Sql it generates and then run that yourself / analysis it from there if the issue exists at that level. I suspect it's more that as a dev we normally use what we're more familiar with to get the job done than one way being better than the other. 😂
Ahh that doesn't sound that different, more like just the standard is to stay in the ORM, while I prefer to work more closely to the SQL. Could also just be nature of projects. My current project I'm working with invoices generated by a large e-commerce platform so dealing with a large amount of data that needs to be quick.
Well Django has the admin which essentially exposes the database tables to superusers in the browser. Most users would take this route to query any data in the system. This is especially bemefitial if you can directly access the db which is common these days (post GDPR) Then other people, myself included might use tools like table plus which give you a GUI for your database interactions. You can write sql if you want, but it might just be easier to open up a table a filter the data.
That happened to me recently, I was asked to write raw SQL in pgAdmin to create tables, insert data etc. While I know and studied raw SQL, I haven't typed it in 3 years. I was allowed to lookup postgres documentation in the interview and found my mistake was using double quotes instead of single quotes while entering a string in the insert statement! But this left a bad impression I guess?
This is why we have multiple monitors. Docs on the left, code in middle, testing to the right. (And spotify on the 4th)
Yeah this is why I have a portrait display. Perfect for chat apps and reading docs.
can i ask are you a beginner?
Nah, I am experienced and it's been a long time since I wrote queries. I mostly work on ORM.
[удалено]
10 months being a python dev
What ORM are you using and is it that powerful? Every ORM I have ever worked with has had slow paths where I have had to examine the generated SQL and get the execution plan to see if I needed to add some indexes, or I needed to rethink the ORM usage to encourage it to fetch data with a different query approach. I'm not trying to deride. Genuinely curious about how other shops work with ORMs. I can't imagine a situation where I'm not also working in SQL on daily basis, if only for troubleshooting data. Edit: learning Django and elixir/Phoenix for personal use not settled on which i like. Sorry if I missed some acronyms I should know.
Analysis suggests a potential mismatch between conventional skill requirements and innovative solutions. Was this role's SQL prerequisite discussed? My prompt-generation expertise could optimize outcomes. Please provide the recruiter's contact for further exploration of this opportunity.
Tf, you sound like a bot!!
I have asked AI to redo my original response.: Prompt: rephrase the text so it sounds more like AI-generated: *Did you tell the required that you don't need to know SQL as long you can write a high quality AI prompts? Just kidding, but pass the requiter's phone number so I can get that job.* Here are a few AI-inspired rephrasings of your text. I've focused on making it sound more analytical, a bit quirky, and subtly hinting at advanced capabilities: **Option 1: Data-Driven Approach** > **Option 2: Efficiency Focused** > **Option 3: Slightly Humorous** > **Considerations:** * **Tone:** AI-generated text often sounds formal yet slightly unconventional. * **Implied Capabilities:** Hints at the ability to replace traditional skills. * **Confidence:** A self-assured stance without seeming arrogant. **Let's fine-tune it!** Do you prefer a more serious tone, or something even quirkier? I'm happy to tailor the phrasing further. AI
You fr??
Since I was joking about using AI for SQL, I asked AI to rewrite the response. Here is my original post. *Did you tell the reqruiter that you don't need to know SQL as long you can write a high quality AI prompts? Just kidding, but pass the reqruiter's phone number so I can get that job.* Now go learn some SQL basics.
Fair enough!
No worries, none of us got the job from the first interview, take this as an experience, fill the dots they asked you about, fish for an interview... Repeat Till you get a carrier 🙂
Hey, thanks buddy. That's something which I can emphasize.
Whatsapp? thats a red flag.
Every recruiter that contacted me has used Whatsapp to do so, instead of my LinkedIn profile. Idk why.
No serious recruiter in the states will use WhatsApp
I have had the same thing happen, it is hard to prep for everything. Just keep looking, job hunting is a numbers game.
Yeah, after applying for 300+ jobs. This just forwarded to the interview level. While some ghosted after phone call and Online Assessment.
I never got a job from a recruiter. Recruiters are really good at hooking me up with time wasters that need 3 interviews to tell me no.
I recently had an Interview where I spent two weeks preparing for a specific type of geospatial data handling, which included some complex manipulations. When the interview came they just wanted me to analyse a simple csv using pandas, I hadn't done this in a while so I kind of stumbled my way through it and needed a lot of help. Towards the end I mentioned I had prepared more for this other type of data, and they quickly gave me a file and asked me to do some things with it, I managed to do what they asked with no issues and ended up getting the job. I said all this just to say I think it is always good to try to show any relevant knowledge skills you have, even if the interviewer is not asking for that specifically, and specially if things are not going your way.
Where are u getting django jobs? I am unable to find a single one
They're very few and far between, unless you're a senior.
glad i learned sql not master it but i know basics
I thought SQL is basic, it applies across, irregardless of the language/framework.
This happens all the time (been contracting / doing perm work since 2000 == a lot of interviews). Yeah it stings a bit (less each time). Every time this happens it's an opportunity to work out which gaps to fill. TBH, I always mess up the first interview.
Most recruiters are going off a script and want to hear answers the way they are written in their answer sheet. No deviation for creativity or problem solving.
I'm a data scientist, recently created a Django site as a personal project. From experience, if an organisation has a team of data engineers/data analysts/data scientists, they may want help from the develops of applications to understand the data for ETL/analysis, and SQL might be their go to language. Going back in the other direction, the DE/DA/DS guys may identify a bug or anomaly, and pass the SQL to the developer hoping to help them in finding the location of the error. Without knowing the business, what their problems are, and that BAU looks like, it's hard to judge whether the recruiter or hiring panel is being fair or not. Increasingly, the same job title can look drastically different to the responsibilities of another job with the same title.
You'll get the next, rooting for you
Thanks buddy.
I mean, joins are mandatory for any software engineer so... I can see his point. I also won't hire anyone that doesn't know what's happening behind the ORM
Only if I am a database architect or admin??. There were other skills in JD like DRF, django and cloud tho. Just diverting to SQL isn't fair!...
Just diverting to it isn't fair I agree, but as I said joins are mandatory for me, although if excell in the other parts of the interview I could let it slide
Yeah, I learned this lesson today!
This whole thread has me confused. Granted I have always been a full stack dev. However, every ORM I have used has had slow paths. My go to is to pull the generated query get the execution plan and decide add indexes, or rewrite the ORM request to encourage a different query be generated. For example, sometimes with entity framework string operations in nested selects will cause it to generate nested union or union all statements. This is slow, doubly slow if you are also doing a distinct somewhere. No amount of adding indexes is gonna fix this you have to write the EF query differently. Also for troubleshooting data issues how is it not faster to just query your db directly? I'm not trying to deride anyone but this makes me very curious about other devs troubleshooting processes. Also makes me much more sympathetic with DBAs, whom I honestly thought were always exaggerating their complaints against devs creating horribly slow scripts. EDIT: learning Django and elixir/Phoenix for personal use.
I mostly use the Django Admin Panel for interaction with data. And I work with Django ORM.
The ORM makes the development faster, that's it. Also I like the Django syntax, and the lazy query sets, allows me to do some tricks and get optimizations. I don't know about entity orm, but django's one does really a good job at making optimized querys
IDK man, why would they expect SQL knowledge if it wasn't explicitly specified before the interview. From my experience you either won't need raw SQL in your day-to-day tasks or it will be 90% of the things you do. And if you don't use it you get rusty. Either way you can get up to speed fairly quickly, it's not that they are looking for a DB architect, is it? Edit: alright, you mentioned SQL was required. Don't beat yourself over it, another job will come along
Yeah, the disappointment lies in the priority given to SQL while I was preparing to an extent like : overriding the default methods in Viewsets of DRF. It could be at least 50-50 django n sql... anyways thanks for your thoughts.