After interviewing thousands of candidates over the years, I say anything is possible. One candidate I recall was 24+ years of development experience mostly consulting in firmware. He graduated from a top school and was referred by our VP of ASIC engineering. Yet he struggled at the most basic C pointer question. He tried everything in the interview to prevent us from asking any coding questions.

Oh my! How can you work in firmware and not know the basics of C pointers? Firmware is mostly C!

I met a professional, working Rails dev who didn't know how to expose a class's instance variables for read access in Ruby. (i.e. write getters)

(Not an interview context though; it was a hack night where I was learning ruby and didn't know the right terms to use to look up that question from the docs.)

Just out of curiosity, did you phrase the question "expose a class's instance variables for read access," or "write a getter?" I see it as the difference between academic phrasing and colloquial.

I phrased the question in many different ways and verified that he understood that I meant, "how do I get the value of @foo from an object of a class that has @foo?" The answer he gave did not hinge on the distinction, and ended up being the ol'

    def foo
      @foo
    end

Maybe 5 years of Java without using inheritance?

It's possible but feels like you haven't gone the distance.

... or you are Rich Hickey :)

I don't thinks so. You don't have to use join, but you might end up with loads of queries instead of having just one, but the end result will be the same set of data.

But if you have loads of queries and do the "join" in your application code, you will suffer serious performance problems with any reasonable data set. If a programmer is going to be writing SQL for anything larger than a toy problem, they have to know how to use JOIN.

Arguably that's one year of SQL experience repeated five times.

Or one week of SQL experience repeated 250 times...

One day?

Arguably.

Yep. Believe it or not depending on the team/manager/programmer that happens very often.

If the data you are querying is spread across multiple tables (and in "enterprise" environments databases with hundreds, thousands, tens of thousands of tables or more are fairly common) then you have to do a join somewhere - in SQL, in your application or even manually. Given that doing the join in SQL is by far the most common scenario not being aware of it is a bit odd!

Or you can use where a.id = b.id and you cover 90% of joins (inner join). I only once needed an outer join in the last 10 years all other cases and here inner joins. And I prefer the where syntax, it's cleaner for me than the join one.

THIS.

Yes, there are SQL statements without Joins. No, we don't usually run them in the reporting organization....

I have 3 years of SQL and while I do know what a join is, I doubt I could write a syntactically correct one that does what it's supposed to do, on a whiteboard. I'd need some test data and access to google, and at least three or four attempts.

Reason is, I work with a CMS that handles 99% of my queries for me. It would be monstrously inefficient for me to go around handwriting sql all the time. Any time it happens is by definition an extreme circumstance, so that's how I do it when it happens - with test data, google, and several attempts.

I'm pretty sure that would be reasonable for most jobs, but I wouldn't pass the tech screen if they wanted me to just freestyle it.

That's fine, but you have 3 years of experience with a CMS. SQL is the Structured Query Language used to make queries, so if you're not writing that, then you aren't working with SQL.

I've been driving cars for twenty years, but it doesn't mean I have two decades of experience with fuel injectors.

Your example makes your point very well. You are totally right.

So you have three years of experience using tool which does the work of generating SQL for you. If you can't write a proper JOIN from memory then you shouldn't be putting "three years of SQL experience" on your CV.