Our SQL interview questions

My first weed out question is asking them to describe a Left Outer Join. They don't have to get it exactly right, I just want to see if they ever did anything more than a two table inner join.

For a Web Developer the first weed out question is to tell me the difference between a GET and an POST. Here all I really want then to know is that a GET is what generally see in the URL and a POST is commonly what you see in HTML Forms. I want to see if all they ever did was ASP.NET WYSIWYG web development or if they actually know something about the internet.

These two questions can be done in a phone screen. The faster that you can weed out people the cheaper the hiring process is.

One initial step I use is to give a description of the problem, then have them actually design the table structure themselves. I then have a printed copy of the structure along with some sample data ready, so that I can refer to specific values (and also to help them visualize the contents).

Careful using that terminology. You'll get false negatives on people who still think in terms of *= syntax, and will tell you that the words "left", "outer", and "join" are all redundant and probably don't belong in SQL in the first place.

I used to be one of those guys, but I'm much less grumpy about it these days so I'd still pass your test. I have a sad suspicion that I'm on the progressive end of the spectrum when it comes to guys who deeply understand SQL.

They're good questions because they go past the two simplest query types:

    select from ... where ...;

and

    select from ... join ... where;

Those are the types 99% of programmers who use SQL for simple CRUD apps know. But they come up short for asking more useful business questions.

Eyeballing the list, it tests subqueries, GROUP BY, HAVING, OUTER JOIN, IN/NOT IN and SUM. Fairly useful primitives for general query writing.

I'd try to add a question that relies on UNION, INTERSECT or EXCEPT.