I like Larry O'Brien's three-part series, "15 Exercises to Know a Programming Language," [1][2][3] mostly for the overall philosophy ("should be tough enough to require problem solving: try to embrace the language's idioms") and for the rationale that comes with each exercise (e.g. implement this to learn that about your chosen language). Note: the internal links between parts of the series are broken, so here are all three parts:
That is an interesting problem set, but with some serious difficulty spikes due to specific problem domains. I use C++ and Go professionally and think I'm pretty competent at both, but I've never had to write a GUI, and wouldn't really know where to start, other than to go read the docs for Qt, try to put together a build script, and then cry a lot - but if I had to do it with a gun to my head, what I'd probably do is write a web server and let the browser be my GUI engine. And then the whole third set... HTTP server/client are both scalably difficult depending on how much library support you lean on (raw sockets to HTTP is approachable, but I'd rather use Boost), but I'd have absolutely no idea where to begin with the email client.
Yes, although this is revealing in itself as to which languages are suited to which problem domains. Also shows up which platforms are suited to what; if I were building a C++ GUI I'd fire up Visual Studio, unless you told me it had to be cross-platform or not-Windows at which point I'd go back to "cry a lot". (Yes, Xamarin, QT, it's still a lot of work)
I think building non-web GUIs may have become harder since 2006, depending on platform/language.