The likely explanation is that your code's buggy.

OK, that's what I thought. It's your approach that isn't correct. Think about it: why would you need to know what are the characters you want to reverse when you just need to know where they are?

Its not actually mutating the input that you're doing wrong. (JS string are immutable).
However, you are actually mutating your array when you don't mean to.
Hint: Reversing an array mutates it. You can create shallow copy with Array.slice().

don't mutate inputs, it's very bad. ;) (Note: I'm not a JS guy, so might be I didn't interpret correctly what your code does)

Mmmmh... I'm not sure I'm following what you say, actually. From what I understand now, this test case could be effectively useful to make fail very inappropriate algorithms. Is that what you mean? Because the "normal" approach to do the task couldn't fail whatever is the input string, actually.

This has nothing to do with the current requirements, it's a completely different task!

Hey! I hope this helps in some way, shape, or form!

With the way you have your helper functions setup, you are intending to return an element, in this case, most likely an integer. However, Array.prototype.filter() determines which elements to select or reject based on the return value of your helper functions. It's looking for a boolean such as true or false.

With that said, the following modifications execute as intended:

function getNonZeroesVersionTwo(element) {
  return element !== 0; // true or false
}

function getZeroesVersionTwo(element) {
  return element === 0; // true or false
}

The call to arr.filter(getNonZeroes), on the third line, is providing a false positive. In other words, it just so happened to work out accidentally. This has a lot to do with the nature of the return value, which is an integer instead of a boolean value. The root of the issue centers on the following explanation: numbers greater than or less than 0 evaluating to true/being truthy values whereas 0 evaluates to a falsy value.

console.log(!!0) // output logged to screen: false
console.log(!!3) // output logged to screen: true
console.log(0 == false) // output logged to screen: true (the "==" operator converts the operands to the same type before making a comparison)
console.log(8 == true) // output logged to screen: true (the "==" operator coerces the operands to the same type before making a comparison)

The return value of the original getNonZeroes will be a non-zero integer, which will be a truthy value, which will signal to the filter() method that the "test" has been passed (referencing the usage of the word "test" in the context of the MDN Documentation). As a result, anything that passed the test will be put into the outputted array.

The return value of the original getZeroes will be 0, which will return the falsy value of 0, which will signal to the filter() method that the "test" has failed. As a result, nothing will get selected or filtered, and an empty array becomes the output.

It is my hope that observing the distinctions between returning a boolean versus returning an element should help guide your search.

Another way to look at things is that filter is already calling the function on every element in the array and is already designed to push elements into an array, it just needs to know (based on a test of true or false) when it is the proper time to do so! All the logic in the if-statements is what it's looking for, while it is already designed to handle the returning part. Exercises that focus on recreating higher-order functions with for-loops and callbacks can be tremendously insightful.

Hope that was helpful ^.^

Your code is not fast enough (for the SIGKILL part). As for the first post, never happened to me.