> Hmm you seem to be laboring under a concept that to know how to join two tables you need to be an RDBMS "expert"
You're misreading. You kept bringing up the point of "expert" knowledge (e.g. in C and for-loops), or knowledge of RDBMSes, and saying you couldn't know X without also knowing Y.
As the question was about SQL, NOT RDBMSes or "expert"-level knowledge of SQL or RDBMSes, I pointed that out.
> On the contrary, if you can't join two tables with SQL, you don't have any "working knowledge of SQL".
Depends on what "can't" you're talking about. I can look it up and then do it. A lot of people don't remember the syntax. Obviously anyone with working knowledge CAN do a join; the question was whether they could tell you how to do it off the top of their head.
Even things you've used a lot, if you haven't used them recently, you'd likely slip up in an interview.
> Every answer you make exposes the hollowness of your supposed "working knowledge"!
Not really. I can make things work (hence "working knowledge") and look up what I don't know and use it right away.
I've been using in-memory databases and of course the equivalent of a JOIN is a basic function but it's not an SQL JOIN.
As noted, there are numerous expert programmers who couldn't do an SQL join in a live interview.
Besides PG, RTM, and TLB, most or all of the Linux kernel programmers, including Linus; Pete Norvig; embedded systems programmers; and on and on.
You could find a lot of people who can handle the SQL you need while screening out brilliant people who are FAR more capable, but just happen not to know item X.
I have enough SQL knowledge to replicate most websites I see. I am also familiar with it enough to look up things I don't know and use them. If that's not "working knowledge", you're using some different definition.
You can have working knowledge of e.g. calculus but need to look things up because you haven't memorized everything yet, and can learn some new method quickly. Someone without working knowledge would simply be lost, no matter what cheat sheets you put in front of them.
> Invalid refutation, I said "if you used an RDBMS and ". That "and" was a boolean and.
Valid refutation. You can use an RDBMS without making use of most of its facilities, and indeed, that is the typical usage case.
You can easily have a non-trivial app which makes what you'd probably consider trivial usage of a database.
> someone claiming knowledge of an RDBMS and not knowing how to do a simple join across two tables is like someone claiming to be an expert in c and not knowing how to write a for loop (let alone use pointers)..
You're mixing up "working knowledge of SQL" with "expert knowledge of RDBMSes". I agree I am nowhere close to an RDBMS expert. However, I can use SQL, which was the point of the original post.
> after claiming to have worked with RDBMS for ages
Something is wrong in your mental model of my description. I used MySQL for years, starting many years ago. I did not say I was an expert in RDBMSes, or used advanced functionality in any sense, and I said the join functionality was done at the application level. My usage of SQL was basic, but I have a working knowledge of it. If there's something I need but don't know, I can read the docs and do it.
> it would take what, one day of reading a basic book on SQL to understand what a join is and formulate a query?
Reading an SQL book doesn't mean you're going to recall the syntax, until you have written queries a number of times by hand. I agree it is not complicated. I do not agree that asking someone to write a JOIN tells you anything about WHY they can't do it.
> The danger of NOT using a quick and easy litmus test is that all kinds of idiots get through to your personal interview stage
You'd probably filter out Pete Norvig, and Linus, and who knows how many other expert programmers, if you asked them to write an SQL join off the top of their head.
> It had just never occurred to me that people who spend their entire lives talking to databases wouldn't know how to talk to them directly.
You're begging the question. Most people who use databases don't "spend their entire lives" talking to them.
Of course I've talked to databases "directly", tuned them, "alter"ed them, indexed them, replicated them, and so forth, but just happened to use logic at the application level instead of the SQL level for JOIN functionality.
It would be nice to see who's upvoting this so I could add them to an IDIOTS file.
Any of the above people could obviously EASILY pick up whatever SQL you happened to be using. RTM could wipe the floor with you, the OP, and everyone else on your team.
If your interview process filters out people like RTM, your filtering is broken.
You can use a database for most of the things most websites use them for without ever using a JOIN. It just takes application logic instead of SQL.
Sites like this aren't exactly heavy on the SQL. This site doesn't even use SQL. Something like Reddit or Slashdot would, but still wouldn't need JOINs.
> I've never yet seen a non trivial RDBMS based app where the existence of an ORM absolved developers from having a good grasp of SQL when they needed to drop below the abstraction layer provided by the ORM.
You don't have to drop below it; you can go "above" it into the application layer.
> If you have a PhD' from MIT and/or have a strong track record of writing Open Source software, creating and selling a startup, build robots (and electric unicylces ) for fun etc, [...] But then if you could do all that why would you look for a job?
Let's consider the case of someone with a PhD who ISN'T famous, and then you give him some kind of SQL test and he fails. "Man, what a load of bullcrap his PhD is! He can't even do a simple JOIN!"
There are a lot of people who aren't "PhD millionaires" or famous open-source magnates and yet are vastly capable. A lot of them don't write joins. And a lot of people who CAN write joins can't do a bunch of other stuff.
You know what else PG doesn't do? CSS. He runs a website but doesn't use CSS or SQL.
So, once again, the danger of using any litmus test is you can end up filtering out extremely capable people who don't do X (but could obviously pick it up quickly), while passing minimally-capable people who CAN do X.
> then I don't think that you actually have a working knowledge of SQL in any sense.
Of course I have working knowledge of SQL, that's how I used MySQL back when we had to write things by hand. I just don't have a working knowledge of JOINs. I could look up the syntax if I needed to use it. [Looks it up] Looks easy enough.
There are numerous SQL commands most users of SQL would probably need to look up.
Arbitrarily deciding that having not-used X means you don't have a working knowledge is a fallacy. Someone else could arbitrarily decide the litmus test is stored procedures. MySQL didn't have those, so instead of using them we had to code at the application layer, and just happened to use application logic in places of JOINs as well.
I don't even remember if MySQL had joins, or non-buggy joins, a dozen years ago. Other people would say, "it doesn't have transactions, so it's not a real database", et cetera, et cetera. You work around limitations and get used to doing things a certain way.
> Unless you're saying "I drew some lines on this piece of paper that represent the strings on the violin; I want you to play the piece of paper like you would the instrument."
Yes, that's it.
> In which case it's a worthless interview.
I'd say the same applies to whiteboards. I have never sketched out code on a whiteboard except in an interview. Of course you can do so and become accustomed to it, just like you can finger a paper violin or piano.
Part of it may be your questions, and part may be HOW you're asking (e.g. over the phone, or putting someone on the spot).
2) Not a lot of people write SQL by hand anymore. I used MySQL for years, long ago, and never wrote a join. Then ORMs came along and handle joins automatically, so I've still never written one. So not being able to do it without looking it up doesn't really tell you anything. I've written far, far more complex things than an SQL join statement. A more pertinent issue I'd be checking for is whether user input is properly escaped to prevent SQL injection -- again, not an issue with ORMs, but an issue when building SQL query strings by hand.
1) A lot of people use languages where recursion is unusual (i.e. NOT Lisp). Even a senior developer (especially of something like PHP) might not recall this, not having actually written a recursive function for years.
3) Representing a car as an object: A lot of software people don't know hardware, so the confounding part might be recalling various attributes of cars and how they relate to each other.
Also keep in mind that many introverted people get very uncomfortable when someone is waiting on them. This can make it difficult to concentrate at all. Being asked to perform on demand is normal for a musician but foreign to most programmers. On top of that, it's usually in an unfamiliar environment, such as verbally or on a whiteboard -- imagine asking a violinist to play on some lines you drew on a piece of paper.
PG, RTM, and TLB would probably fail your test -- they don't use SQL, they use flat files.
You're misreading. You kept bringing up the point of "expert" knowledge (e.g. in C and for-loops), or knowledge of RDBMSes, and saying you couldn't know X without also knowing Y.
As the question was about SQL, NOT RDBMSes or "expert"-level knowledge of SQL or RDBMSes, I pointed that out.
> On the contrary, if you can't join two tables with SQL, you don't have any "working knowledge of SQL".
Depends on what "can't" you're talking about. I can look it up and then do it. A lot of people don't remember the syntax. Obviously anyone with working knowledge CAN do a join; the question was whether they could tell you how to do it off the top of their head.
Even things you've used a lot, if you haven't used them recently, you'd likely slip up in an interview.
> Every answer you make exposes the hollowness of your supposed "working knowledge"!
Not really. I can make things work (hence "working knowledge") and look up what I don't know and use it right away.
I've been using in-memory databases and of course the equivalent of a JOIN is a basic function but it's not an SQL JOIN.