From talking to some people who give out these interviews, most of those points really don't matter at all. What matters is A) getting a correct solution and B) being able to explain how you arrived at the solution. Tests, idiomatic code, clean design, etc are not expected and will inevitably waste precious time. Besides, the very nature of the interview (using a walled-off in-browser pseudo-IDE) restricts you from actually writing best-practice code.
As a counter point, I was in an interview loop recently with a candidate that ended up solving the question eventually, but didn't hit a lot of the bullet points in the parent comment (asking clarifying questions, edge cases, abstraction).
After discussing feedback from other interviewers, it was apparent that the same considerations were lacking in multiple interviews, and so the candidate got a no hire decision. For any single interview it probably would have been okay to omit these things, but when there's a negative pattern across multiple interviews, that's when it really hurts your chances.
How do you expect to convince the interviewer that your solution was correct without tests? How can you debug your code properly if you end up with a spaghetti mess instead of using a clean design?
Testing and debugging vary from site to site. Most of the ones I've used run your code against a hidden suite of tests to check all possible edge cases. This would otherwise take up a very non-trivial amount of time in the session. Actual debugging is also not possible on all of the sites -- usually the most you can do is litter your code with logs, which is far from a clean design.
