There are a lot of people who've used SQL, and therefore will think it's perfectly honest and accurate to list SQL experience on their resume, and who've written perfectly fine queries to get shit done, and yet they would not be able to answer that question, especially in an interview/interrogation situation.
Also, in real life, under normal working conditions, we live in the Age of Google (and books) -- if someone ever needed to know the definition, or recite a definition or comparison of those terms, he could just look it up. A better question would be: can they solve problems? And solve them in good ways? And have they in the past? Do they get shit done? Ship? Reliable? Work well with others (to the extend it would matter, because it varies)? Would it be a net win to them involved with your project/team/company? Those questions matter the most by far. And I don't think it's wise to assume they're going to be able to recite a definition of any particular term. Offhand. In a stressful and unnatural situation like an interview.
There's a still a certain level of familiarity with the subject matter required to do a job. If the role can be defined as an "SQL job" (say something in data warehousing or reporting) - not knowing what types of joins are available could lead to terrible solutions.
I would agree with you if the interview question was more specific, say about Oracle window functions for example.
An SQL developer not familiar with full joins would be similar to a Java developer who is not familiar with interfaces, or a Javascript developer who has never heard of closures. It's a significant part of the language, not a piece of arcane reference.
You know, that's a fair point. I think our company may be making that same mistake where instead of trying to find the good candidates, we're trying to filter out the bad ones. I'll see if I can change that.
Comments
There are a lot of people who've used SQL, and therefore will think it's perfectly honest and accurate to list SQL experience on their resume, and who've written perfectly fine queries to get shit done, and yet they would not be able to answer that question, especially in an interview/interrogation situation.
Also, in real life, under normal working conditions, we live in the Age of Google (and books) -- if someone ever needed to know the definition, or recite a definition or comparison of those terms, he could just look it up. A better question would be: can they solve problems? And solve them in good ways? And have they in the past? Do they get shit done? Ship? Reliable? Work well with others (to the extend it would matter, because it varies)? Would it be a net win to them involved with your project/team/company? Those questions matter the most by far. And I don't think it's wise to assume they're going to be able to recite a definition of any particular term. Offhand. In a stressful and unnatural situation like an interview.
There's a still a certain level of familiarity with the subject matter required to do a job. If the role can be defined as an "SQL job" (say something in data warehousing or reporting) - not knowing what types of joins are available could lead to terrible solutions.
I would agree with you if the interview question was more specific, say about Oracle window functions for example.
An SQL developer not familiar with full joins would be similar to a Java developer who is not familiar with interfaces, or a Javascript developer who has never heard of closures. It's a significant part of the language, not a piece of arcane reference.
You know, that's a fair point. I think our company may be making that same mistake where instead of trying to find the good candidates, we're trying to filter out the bad ones. I'll see if I can change that.