Coding tests are quite special, in that the surrounding documentation/tests/comments are often more important than the solution itself. A prospective employer is interested to know not just that you can code up a solution - they want to know you understand how to research and design a solution, and then be able to explain it to your future team. A technically correct solution that nobody else on the team can understand isn't useful in a work environment.
For this sort of test I always make sure to refactor the code into nice logical functions/classes before submitting it. Remove or thoroughly comment any “cute” code (i.e. any weird coding tricks a reviewer might not be familiar with). Write a suite of unit tests that explicitly calls out any edge cases or unusual behaviour of the solution.
And once I've done all that, I add a readme. The readme contains really obvious things like “copy paste these commands to compile and run the code”, but it also contains a detailed section where I describe the algorithm I chose, and why I chose that algorithm (with a discussion of alternate approaches I considered, and the trade-offs/drawbacks to each approach). That last section is really critically important: it shows the reviewer that you actually understand how your solution works, and aren't just copy/pasting algorithms from stack overflow.
