Ha, that was the first thing I checked. No, I wasn't. Code passes now with your new translation. Thanks for doing that.

The random tests on JS all expect the output to be unchanged from the input. Writing return leaderboard passes all random tests, and looking at error messages for correct code that passes the single basic test bears that out (input abbreviated):

leaderboard = ['VCW', 'Rhp', 'EyD', 'XLb', 'cMh']
changes = ['XLb +1']

// Expected:
['VCW', 'Rhp', 'EyD', 'XLb', 'cMh']
// Actual:
['VCW', 'Rhp', 'XLb', 'EyD', 'cMh']

Also, as noted elsewhere, the tests all seem to test a single change rather than a variable number of changes.

Can you say more? What part did you find ambiguous?

Stable sort in JS!!!!

(╯°□°)╯︵ ┻━┻

It would be more memory efficient but less readable. Whether or not to make that tradeoff is your choice.

In production code solving a problem like this and assuming I wasn't operating in a resource-constrained environment like an embedded device, I would choose readability over saving the memory overhead of assigning a float to a variable every. single. time.

Thanks for flagging! Posting here for posterity: after discussion directly, I think these failing cases were due to not handling the input case flagged in this part of the instructions:

It's important to note, though, that if all data appears the same number of times there is no mode. So "cat", "redder", and [1, 2, 3, 4, 5] do not have a mode.

Python translation: https://www.codewars.com/kumite/5c353db677bd7266e019153c?sel=5c353db677bd7266e019153c

Finally figured out to resize the window to get the right buttons to show up :(

Fixed.

Yup, you're right. random_min = generate_random(30, 100) should be random_min = generate_random(30, random_max - 1)

I'm not sure how to update that right now :(

Python translation submitted here: https://www.codewars.com/kumite/5c2ec5d4dc33a50008c07308?sel=5c2ec5d4dc33a50008c07308

@LucasZapico, I would never, never trust or believe that the solutions voted "Best practice" on this platform are actually industry best practice. In fact, often the reverse is true, and you'll see that witty or terse solutions are the ones that tend to be upvoded as "Best practice" over actual best practices.

Thanks, you're right. I went ahead and updated the description to exclude zero-length lists.

I've updated the tests and I believe the update addresses this issue. @kazk let me know (or update directly) if the update is improper somehow.