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