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.
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'
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.
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.
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.
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.