Can someone accept this? All issues are resolved...

There are few places, where CPU cycles are totally wasted.

• prime_factors are executed for each element of the array twice
• in prime_factors you don't need to count all factors - if cnt is greater then k, you can stop searching.

And repeated random test also added...

Headers added.

@Steffan153 - 50 of what? Repeats?
I completely don't get the approach to random tests at codewars. IMHO it would be best to have fixed RNG seed and some number of randomized test cases - so they are random(ized) but repeatable. (On my other solution, I was pointed, that fixed RNG seed is bad, because it's not random that way...).
IMHO random test cases should test how the solution works on bigger dataset, that can't be easily hardcoded. All the corner/edge cases should be tested in normal tests.

And regarding headers - everything compiles and executes correctly - why should I add headers that are technically unnecessary and only obfuscate the source code?

Original task has no random tests.
TBH there is no reason for more random tests - they will be basically the same. I can loop to test more than one strings, but it seems pointless for me.

Thanks for review.

Fixed all issues.
Original task (Rust translation) has no random tests, but I added them for C++.

Fixed - seeding with current time.

Hi! I created Go translation of this kata. Please take a look: https://www.codewars.com/kumite/5bef24a4aef7123f4700023c?sel=5bef24a4aef7123f4700023c

Instead of calculating limit with conversion to f64, calculation of sqrt, etc, you can use simplier operations like while i*i <= n.
Reverting of u64 can be done without chainging to string, with modulo division.

I love how the backwartds_prime is implemented :D

It seems that Rust tests are broken. The second example require returning 4 steps (same as input) while in contents of kata, expected return is [].

I'm unable to submit my solution (C++). After clicking Submit button, there is some processing, but status is 0 Passed tests and 0 failures.

This code is unreadable and has tragic performance. There is no reason to convert number to string and then back again.
Using std::make_pair seems to be better way to create pairs in C++.