Problems are not all the same: choose one that stresses and challenges the language, to gain confidence in its strengths and practical expertise.
For example, I once tried to learn Haskell and I started from little exercises (https://wiki.haskell.org/H-99:_Ninety-Nine_Haskell_Problems)... I got familiar with syntax and basic concepts, but I was dissatisfied both with the easy, abstract questions and with the simplistic, inefficient answers using basic standard library features that are more or less the same in any language. What was "real" Haskell code like? I expected dealing with serious libraries, memory management etc. would be uglier, more difficult and more cumbersome than exceptionally terse toy examples.
So I attempted something not merely useful and small, but with a well defined practical objective, depending on external standards, requiring production quality libraries and with performance challenges: converting the metadata dump from MAME (a nearly 200MB XML file) into an easy to use SQLite database.
The task was a good test of programming language productivity because, having already used ElementTree and APSW I was sure I could write it in Python quite easily. (And I did; a complete Python implementation, able to roundtrip data back to the XML format for testing purposes, took me less time than an aborted Haskell attempt that could parse a dumb document tree using a ridiculous amount of memory.)
This project allowed me to discover many things about Haskell that are not found in enthusiast-written tutorials: the mess of incompatible and undocumented libraries, the impracticality of basic language design decisions (text handling, lack of namespaces leading to name conflicts, etc.) and my profound disgust for the commonplace syntactic tricks.
Of course, a similar challenge for Python is likely to have a better outcome: learning the difference between good and really good libraries, finding a use for many language features, remembering useful idioms nd design patterns, etc.