This problem is NP-Hard, so it's unlikely it can be made any more efficient.

In rust, I honestly don't know how I could make my code any more efficient, it runs in 1362ms on the test case. This is pretty quick and usually is enough to pass the larger tests, is there some super quick algorithm I'm supposed to be using?

Never assume your code not working is an issue. An issue is a bug in the kata and it needs to be proved. I strongly advice you to read carefully the official recommendation page: https://docs.codewars.com/training/troubleshooting/

It is a little confusing. Regarding the example, this may help a bit. I don't think it's a spoiler.
maxSequence([-2, 1, -3, (4, -1, 2, 1,) -5, 4])

Got it, thanks!

I'm gonna list only the skip steps, in the middle fill them with a step of 1:
15350, 15355, 15365, 15375, 15385, 15395, 15500.

The change is, instead of going from 3 to 4, it changes from 3 to 5, but only when it should be 4. You're thinking it should change 3 for 5.

Thanks for explanation, but I still don't get it. It is writen " This defect shows up in all positions (ones, tens, hundreds, etc)." So, in my example, for 15350 3 in hundreds changes to 5 and we get 15500. Aga, seems like I miss something here.

I'm sorry, I don't understand why this is happening. The generator has been fixed. I can publish a new fork (but there will be no difference with the currenc tests), someone needs to approve it first: https://www.codewars.com/kumite/627ffdc0a2670b003d770406?sel=6282288017c6bf8c839675dd

Read the comment by 'NHerwich' from about 8ish months ago(prior to my comment). That person explains the basics, the kata description talks about if all numbers are negative or if the array is empty. One other maybe helpful clarification is that a single(positive) number in an array can be the answer if it happens to be the only number, only number > 0, or if no other amount of numbers added together is greater than it.

Rust implementation, random test:

I run the test 2 minutes ago. The random test cases were:
104, 6093, 2070, 5069, 4039, 90392, 80318, 6092, 604 ...

Like in the Go random tests (see issue above) the fix in the Rust random test is not yet active.

I fixed the translation directly, but for some reason the tests still use the old number generator. I published this new fork (where one cannot see any difference, since the generator is ok): https://www.codewars.com/kumite/6280e8bff1b9edb55bb7dc6a?sel=6281ae9817c6bf0024967483

Go: Inputs in random tests may contain the digit 4. This should not be possible (the odometer is faulty).

The real miles number can contain 4. Let's see 55: it skips 4, 14, 24, 34, 40 and 54, so 55 - 15 = 40.

Javascript implementation:

"For n = 2003 the output should be 1461." how can the answer be 1461 if it always skips 4?
The same goes for the following test situations, all of these answers contain a 4... or am I missing something?

Test.assertEquals(faultyOdometer(55),40)
Test.assertEquals(faultyOdometer(2005),1462)
Test.assertEquals(faultyOdometer(999999),531440)
Test.assertEquals(faultyOdometer(2005),1462)