I would disagree. There are questions which if you fail to answer this means your understanding of the field is near zero. For SQL, I would say question about "which kind of joins there are and why" is like this - if you don't understand this, you don't understand relational databases. Which may be OK if the job does not require that, but at least you'll know that about the candidate.
Another thing is that some candidates (or their recruiters?) "inflate" their resumes claiming expert knowledge for things that they heard about in passing or maybe did some trivial task with it. Asking such trivia knowledge allows to find it out very quickly - if one claims to be SQL expert with 5 years of experience and don't know what inner join is - he's probably lying. And this is a bad sign - to start relationship with a lie. I know some people like to do that (especially because of the keyword-match approach) but it's a huge turnoff to start an interview with a supposed expert in the field you need and find out the most work he did in the field was a toy project 10 years ago in college of which he remembers nothing and isn't even interested in doing that.
> For SQL, I would say question about "which kind of joins there are and why" is like this - if you don't understand this, you don't understand relational databases.
This is like saying if you can't write a controller in Ruby on Rails off the top of your head, you do not understand programming. SQL is a vendor-specific technology, and while it is related to relational databases, is not tied to the underlying theory. You can have a relational database that does not use SQL at all.
> if one claims to be SQL expert with 5 years of experience and don't know what inner join is - he's probably lying.
I agree with this. If you want to hire someone who understands the inner nuances of, say, MySQL then it may be a good question. This is quite a bit different to understanding relational databases though – one is theory, one is application.
No, it's not like that at all. RoR is a very specific application, if you can't write a controller then you probably don't know RoR, but it doesn't say you don't know programming in general.
Yes, you can have relational database that doesn't use SQL at all - how many of those are around and popular though? There are some, but not many. What are the chances that you worked with a lot RDBMS, yet never encountered SQL even at the basic level, and it is not immediately evident from your resume, which still says "SQL"? But OK, if that's the situation, you can say "you know, I worked with non-SQL relational databases, and let me tell you about this cool thing I've done that is way better than SQL JOIN can do" - and that might be fine too. Usually though the case is just that people inflate their resumes and think they won't be called out on it. It's very unpleasant because when you interview somebody whose resume looks good, you unconsciously plan that you'd get a great addition to your team - and then you discover he doesn't even know joins... Bummer.
BTW, inner join has nothing to do with MySQL inner nuances - it exists in virtually any SQL implementation out there AFAIK.
Another thing is that some candidates (or their recruiters?) "inflate" their resumes claiming expert knowledge for things that they heard about in passing or maybe did some trivial task with it. Asking such trivia knowledge allows to find it out very quickly - if one claims to be SQL expert with 5 years of experience and don't know what inner join is - he's probably lying. And this is a bad sign - to start relationship with a lie. I know some people like to do that (especially because of the keyword-match approach) but it's a huge turnoff to start an interview with a supposed expert in the field you need and find out the most work he did in the field was a toy project 10 years ago in college of which he remembers nothing and isn't even interested in doing that.