Short and sweet, but not best practices. I think this is a cute and clever solution for a simple string, but not efficient if the input was 100s or 1000s of characters long. I'd prefer a solution that returned false as soon as a lowercase character was found. In this case this solution is O(n) yet always the worst case, meaning that it always has to reach the last item (ALL characters must be uppercased) before it can determine the boolean value. This is more of a JS like solution than an Elixir solution. Elixir has better "tools" for working with strings.

This is very clever!!!

Yes, it's O(n^2). No, you're thinking too much and in fact that's just total nonsense. It holds true even in psuedo-code form.

Duplicate, not actionable.

Not an issue.

.

I dunno his benchmarks ~10x faster than yours does.

My code had problems in dealing with numbers that are more than 4 digits long. There are no such numbers in example tests. I used 20000 and 1, with expected output (3, 10000, 21001): 1000, 10000, 10001.

I can't get any of the random tests to pass....
I really liked this Kata but I have an eerie feeling it isn't my code that is the problem.

I had no idea about map_size. And it runs in constant time too!
Makes my solution look so convoluted

yeah but this is ranked as a 7 kyu?