Once, I applied for a job and all of the technical questions were about SQL, because I had listed that as a technology that I knew. One of many, by the way, and not something that I claimed mastery in or anything. It was just those three letters. Somehow, the interviewer thought that meant I’d have a DBA’s knowledge of the subject.
I get DBA interviews, but don’t understand SQL interviews for software engineer type candidates. It makes some sense for like business analysts but even then, let them Google syntax.
Like if you can’t figure out joins and subqueries in 30min of googling tops, you’re probably not a good fit for a software engineering role anyway and will hopefully have issues elsewhere in the interview screen and for syntax it’s not super exotic, you can just Google it especially for things that change depending on the dialect of SQL you’re using.
I don’t disagree with you essentially, but 30 minutes is ambitious, in my opinion, to really figure queries out. I’d much rather have a slower person who actually understands what they’re doing than a faster person who is probably just copy-pasting from ChatGPT.
I tend to write production queries more than one off analytical ones, but if your query isn’t relatively straightforward to understand, you probably modelled the data wrong in the database.
Conceptually, inner / outer joins are relatively simple compared to other concepts you need to know when writing software professionally which is where that comment came from. If you’re a business analyst or similar and not as experienced with expressing thoughts in a structured language and understanding how to evaluate the performance of that, I understand wanting to screen for that because it’s not assumed you would be familiar with that off the bat.
I’m coming at this from a pre-chatgpt mindset, where you are still googling for syntax and a list of which aggregations or operations are supported. Like casting data types is often different between SQL dialects.
Once, I applied for a job and all of the technical questions were about SQL, because I had listed that as a technology that I knew. One of many, by the way, and not something that I claimed mastery in or anything. It was just those three letters. Somehow, the interviewer thought that meant I’d have a DBA’s knowledge of the subject.
I get DBA interviews, but don’t understand SQL interviews for software engineer type candidates. It makes some sense for like business analysts but even then, let them Google syntax.
Like if you can’t figure out joins and subqueries in 30min of googling tops, you’re probably not a good fit for a software engineering role anyway and will hopefully have issues elsewhere in the interview screen and for syntax it’s not super exotic, you can just Google it especially for things that change depending on the dialect of SQL you’re using.
I don’t disagree with you essentially, but 30 minutes is ambitious, in my opinion, to really figure queries out. I’d much rather have a slower person who actually understands what they’re doing than a faster person who is probably just copy-pasting from ChatGPT.
I tend to write production queries more than one off analytical ones, but if your query isn’t relatively straightforward to understand, you probably modelled the data wrong in the database.
Conceptually, inner / outer joins are relatively simple compared to other concepts you need to know when writing software professionally which is where that comment came from. If you’re a business analyst or similar and not as experienced with expressing thoughts in a structured language and understanding how to evaluate the performance of that, I understand wanting to screen for that because it’s not assumed you would be familiar with that off the bat.
I’m coming at this from a pre-chatgpt mindset, where you are still googling for syntax and a list of which aggregations or operations are supported. Like casting data types is often different between SQL dialects.