Then why didnt you complete the hard sudoku solver??

It actually takes 3N iterations. The result can be found by the third number, so no real need to loop further.

Sometimes I feel we FE devs get so caught up in functional programming we forget about efficiency of implementation.

You don't actually need to even traverse the entire list in most scenarios.
In a best case scenario you can return after just 3 iterations, for example, let's assume the target value (in this case odd) is at index 0 in the array. You record the index of the odd value within an oddIndexes list. You then make a further iteration and find an even value which, the index of which you store in an evenIndex list. You then make one more iteration and find another even value, at this point you now know the target value has to be odd of which you already have the index stored.
Worst case scenario is that the odd value is at the end of the array and you have to iterate the whole way through.

Agreed, I tested this vs my solution which I thought was bad, turns out mine is 3x faster

I concur. I was looking at this and noticed that it traverses the list of N items twice just to get the odd, even lists.
Also... I don't think the parseInt map was necessary. Would that be considered another pass to the list? 3N iterations instead of N? Clever that it is only 4 lines of code.... But not very effecient for large N.

Corner cases covered =)

This is totally not 3 kyu ( compared to other 3 kyu) .
Random test generator may be 3 kyu. This one is definetely 5 kyu. solved in 30m

Hm, i wouldn't call this clever. This takes 2N iterations instead of N

how this works !?!?!??!?! wtf

what if time parts included months and weeks and maybe something else ....
refactor switch with loop or array.join

solved in an hour, and it seems like i got 2 points of honour for it.

badass