I agree the problem itself is trivial. The bonus in the description adds a small layer of puzzle-like complexity. However whatever complexity this adds has less to do with knowing how to write code than it does finding clever ways to compute the upper section in Yahtzee.

Also, I like your profile picture, is that from Neverhood?

Thank you, fixed.

Thank you for pointing that out.

Adjusted tests to be randomized.

The only thing on CW that can be considered "content", as in, "have any worth", is the katas. The rest, including whatever community that might exist, is, frankly, pretty garbage...

Only reason I'm continuing this thread at this point is to add that the members of the CodeWars community helped me learn how to author my first Kata. Just because it has no worth to you doesn't mean it has no value.

I updated the description to reflect your input.

For clarity, this is my first authored Kata and I'm learning the ins and outs of it. I know you probably don't have a way of knowing that, but a lot of your input has been condescending and rude. Not once was I rude to you, but rather took in your input and made the changes.

I appreciate the advice you've posted here as it has definitely improved the description of the Kata, but others who are learning how to do this may come across your style of input and give up entirely. Just a thought.

I updated the description again to hopefully provide a more clear comparison for the values in the input.

"Given an array of dice rolled per field where 0 <= dice <= 5"

The input array is not the value of each die rolled for one given round. Each number in the input array is the number of dice you rolled for each given field in the upper section after the game has been finished. This is covered in the description.
Input:

[2, 3, 3, 3, 4, 2]

In this input, the player rolled 2 ones, 3 twos, 3 threes, 3 fours, 4 fives, and 2 sixes. That is the total tally of dice rolled for each field in the upper section.

If it were the case that I'm showing you one round of dice, the input array wouldn't be length 6, since you're only rolling 5 dice at a time.

I adjusted the description to specify that you can assume the game has already been played, and all fields have been already filled in.

return arr.join(' ') === '' ? null : arr.join(' ');
return arr.join(' ') ? arr.join(' ') : null;
return arr.join(' ') || null;

A couple ways to refactor your return statement. An empty string in JS is a falsy value, so you can just check the boolean value of the string.

Tests are horrible. Debugging is near impossible with random tests. On top of that, sometimes just adding console.log() will all of sudden pass random tests.

I like this answer because just about anyone could read it and understand what's being done.

I'm not quite sure if the time complexity of the solution would change if you split str once outside of the for loop rather than splitting each chunk inside your sumCubes function. Thinking about it, if str is length === 5000 and sz === 5, you'd be calling split 1000 times, plus any additional times if the sum of it's cubed digits is even (max another 1000). You're obviously calling split way more, but you're technically iterating over the same number of elements. I like the solution though, clean and easy to understand.

Good O(N) solution. A lot of other solutions utlize splits, maps, and joins (all O(N)) which together significantly increase the runtime for this problem if the input string were millions of characters long.