The problem with hard SQL problems is that they are often one of two camps: 1. use some underlying implementation detail of the particular RDBMS or proprietary

The problem with hard SQL problems is that they are often one of two camps: 1. use some underlying implementation detail of the particular RDBMS or proprietary extension to the standard 2. are essentially tricks, like the typical ridiculous interview problem designed to "make you think outside the box". Yes, you can do almost anything in SQL but often you should not. I get the perspective here is data analysis where you probably need to know more SQL than the standard developer, but I still feel you should be testing for solid understanding of basics, understanding of the relational algebra concepts being used and awareness of some typical gotchas or bad smells. That's it. They'll be able to google the precise syntax for that tricky by date query when you're not guaranteed to have data for every month or whatever on-demand.