I have used joins and subqueries (in the where clause) in the past. But when I look at many of the exercises, there's a partially-written #SQL query that uses these features and CTEs and it is difficult to reason about the query and its pieces. Normally, that's when I'd write some exploratory queries to understand how to go from a set of tables to a specific result set (itself a table).
But the table rows seen in the preview may not be easily visible in the query results, which makes it more difficult to see whether one is on the right track.
With SQL, at least, it seems to be an artifact of the way their hands-on code runner works (Displays a short `head` of the relevant tables ... so when you're working on queries, you may not have a direct way to see whether your query does specifically what you expected and intended.)
With R-Lang, it is just that it isn't always apparent what the language will do. Some things are inexplicably backwards compared to most other languages I've seen, so mentally I tend to go with the wrong choice. Also, the practice question set is too small. I've reached the point where some of the practice exercises are familiar enough that I know which answer to choose immediately without having any understanding of why that is the correct choice.
Now talking to someone from Cockroach Labs about distributed #SQL databases and the current inflection point caused by #COVID-19 related "work from home". #CockroachDB