These aren't "details memorised from a manual". These are fundamental primitives of SQL queries. You simply cannot express most serious questions without them.

If someone came to me and I asked them to write fizzbuzz, an answer of the form "I would google if-thens and modulo and print statements" would be a pretty obvious no-hire.

I would imagine questions that are good to start with: how you as a developer usually start a design of a database? How do you plan it? I got this question once, I thought it was really good. On the spot I could tell the engineer who asked me that is experienced. Can't answer that after reading sql book two days earlier. In contrast to the questions from the post.

In a business setting, the conceptual/relational, logical and physical design of a database happens far less often than querying such databases.

Indeed, one of the reasons normalisation is such a Big Deal to relational bigots like me is that it makes SQL's querying tools much more useful and versatile.

True story, but such questions are just senseless.

If someone knows about set-theory and the ideas behind query-languages, knowing SQL isn't a deal breaker, it's just a nice to have.

Folk generally don't study relational algebra, on its own, for fun.

SQL is one of those technologies that caps how much enjoyment you can derive from understanding the related theory. Scheme, for instance, never stops giving, but you can hit a point with SQL where you start to wonder: where's my Tutorial D?

And where are my proper temporal primitives?

It sucks, but it's what we have for now.

They really should.

If someone knows set theory, they're likely not interviewing for a LOB CRUD job banging out Rails models.

What if you're not looking for an experienced data modeller, but someone who can write SQL?

Also: If you can read the SQL book two days earlier and answer these questions in a reasonable amount of time - sounds like an insta-hire to me. There's certainly nothing so hard about SQL that you couldn't do that - but some people who spend a lot of time working with databases seem to find the climb insurmountable.

When I learnt SQL, the part that took me the longest to square away was the distinction between WHERE and HAVING. It was thoroughly confusing at the time.

Once you grasp that conceptually, SQL generally executes left-to-right, it's easier.

I avoid `having` wherever possible these days. There are data analysts in my team that I know would have to think twice about it if they encountered it in my code, and to be honest, it's a bit of an wart in the SQL grammar anyway.

In (almost) all cases, a subquery with an extra `where` clause will have equal performance to a `having` clause in the main query.

See the final example in: http://en.wikipedia.org/wiki/Having_(SQL)

If my datastore is a SQL database, I don't want you modeling anything if you can't answer these questions.

I think you'd be surprised the percentage of people who would fail to answer these (remembering how many can't answer fizzbuzz). I wouldn't read the answers to them as any measure of real expertise, just you're talking to someone who knows their way round a database and can apply the basics - you'd be shocked how many people who "know" SQL can't use GROUP BY (even when prompted). For a lot of people SELECT, FROM, WHERE is SQL.

In terms of "what would you do if" type questions - they're often no less prone to book answers. What you really want is "give me a specific example of when this happened to you and how did you behave" as they're more likely to test real experience. Sure people can lie but when you start digging into it few people are good enough to continually make up exact details on the spot without getting suspiciously vague (or having behaved in a suspiciously perfect manner).

3rd paragraph of article:

"Some people might say it is too basic, but that's not the point. The test's job is not to tell genius and rockstars from "normal" devs. The purpose is to save you time and quickly filter out DB-experienced guys from the ones that just claim to be."

Rockstar questions would start with window functions.

(Not it!)

You raise a good point about interviewing via trivia questions but I think you'd have to agree that for someone to know a subject there is an inherent amount of information that a person needs to know.

What that line is can be fuzzy.

Consider C, what is the difference between the stack and the heap? yes you can look this up but if a candidate doesn't know this cold then they just can't write C code properly.

Simiarly for sql if a candidate can't write a simple join then it's pretty obvious that they haven't really used sql before.

The sql questions asked here are somewhere around the fizzbuzz level of skill. Any sql user should be able to answer them given a properly setup dev environment.

An interview is a conversation, which is a very high bandwidth medium of information exchange. But in order to get to the level of conversation, both parties need to be speaking the same language. What this test establishes is the baseline level of common language that makes it even possible to have a conversation about SQL databases. Someone who can't handle these sorts of questions is not someone I can usefully have a conversation about SQL with. I can teach them, and sometimes it's useful to have a pedagogical sort of interview; but for a standard, "can you do this job" interview, no, I need to be able to establish a baseline level of common understanding.

Keep in mind that most of the time there are different solutions for a problem. They all finish the job but some are better than others.

Knowing why and which solution is best will get you the job.

I don't run a school. Anytime a web-developer does not know basic sql or other basic knowledge, I refuse to pay salary, and even deduct the 1$ per minute. That five minutes just cost you $10

Not a big fan of on-the-job training, then?

Instead of paying a nominal price for people relearning some primitives for a specialized area of IT/software dev, nowadays most companies want the new kids to go to $80,000 worth of college for the same. That way, the employer gets to skip training, and the student is less likely to leave because he or she has too much damned debt to be mobile.

Maybe I'm projecting.

Actually I am a big fan of it.

But I'm not a fan of people stating that see these kinds of tests as an attack, or see it as something which is unnecessary. There are a lot of people out there are unable to answer these questions, even with "google". And most of them are either unwilling or unable to improve themselves.

I'd rather have a very eager "junior" who loves what he does, and works hard to understand and develop him/herself than someone "senior" who knows a couple of tricks and is too arrogant to do these kinds of tests.

You keep people if: * they can improve / if they learn * if the colleagues are nice * and the product is interesting, aka they have meaning * management is done reasonably * there's a future for them

this is why startups are popular (learn lots of things, meaningful, good upside) as well as corporates (carreer path is flexible, good management, etc).

Refuse to pay salary? Good way to end up with a terrible reputation and/or a broken nose.

We are going to have to deduct a few dollars for your lack of basic multiplication.

Ignoring the fact that 1$/minute * 5minutes = 5$ -- I wonder which _knowledgeable_ person is willing to work with someone who thinks like you do...

I said I wouldn't be paying the salary + even deducting $1 which is $2 per minute.

This person did not qualify to be _knowledgeable_, as he refused to do this test ;)

I'd guess that's a labor law violation in most developed nations.

Bet you have one happy bunch of motivated developers working for you... that's an 'interesting' management style.

Most likely no one.