Though in this case, the downvotes mostly come from the O(1) requirement not being enforced at all.

This. Otherwise it looked good to me.

1st rule of TDD: the spec is practically defined by the tests, not how the description is written. If the tests simply allow any code to pass, then there are practically no specs, so of course the blame goes to the kata author of writing a dubious test fixture ;-)

As mentioned above, I think if you read this in the description and disobey it then you're just cheating yourself

If you claim that something has to be done in a particular way, then your tests should ensure that the requirements are met. Otherwise, the design is simply bad.

I suspect there's some built in way or a convention for testing Big O in Codewars

The author should write tests which won't allow inefficient solution passing - there's no other way around.

Well, in general katas about basic interview questions (or problems which source can be easily googled with answer directly read from there) are not very good kata ideas because

• The answers are available everywhere
• Usually they're not really novel
• It tends to encourage people just plagiarizing problems from other sites to CW without attributions (which if you have noticed, consistitutes a non-trivial part of approved katas). This is really hairy as it quickly approaches the "copyright issues" territory

I typically raise an issue about the 3rd point if I happen to find the exact source because attributions are important.

Though in this case, the downvotes mostly come from the O(1) requirement not being enforced at all. It's up to the kata author to make sure everything works and there are full test coverage before publishing ;-) If it gets retired, rework on the kata again and try again, but if the idea itself is not very interesting to begin with, the second try might not be very successful either.