I have been reviewing a lot of code submissions for potential candidates to hire. And a lot of candidates make similar mistakes. Here is a short list of things I would recommend to someone submitting a code sample to an employer:
Test-drive your code
All of it. No exception. Write the test first and then code to the test. Make sure your tests are proper unit tests (i.e. testing a single function). We get a lot of submissions with a few higher-level tests that are there to prove that the sample input we give out actually produces the sample output. These tests are okay, but they are not a replacement for unit tests. And if you’re really serious about your submission, read TDD by Example before writing your first line of code.
Do not add comments
It is perfectly fine to submit your code without any comments in it. In fact, that’s encouraged. This is contrary to what most schools are teaching but it is still the right thing to do. On the teams I’ve been on, junior programmers add comments to the codebase and the senior ones delete them. The only documentation you should provide is a README to quickly state your assumptions and to explain how to compile/run your code. If the comments are really necessary because the piece of code is complex, rewrite that piece of code.
No showing off
Do not over-engineer in order to show off. Your submission should not be a showcase for all the patterns you know. If you’re coding in Java, keep interfaces to a minimum — they are usually noise. In general, do not do anything based on potential future requirements. The goal is to keep your submission short. The only form of yak-shaving that I could potentially agree with is error handling. If you’re so inclined to handle all possible failure scenarios, go ahead.
Simplicity is key
Keep your methods short and readable. By short, I mean less than 10 lines. Try not to nest your control structures inside one another. A triple-nested if within a try/catch block is a huge turn-off. Related to that, following the Single Level of Abstraction concept is a good idea. For what it’s worth, you might also consider following a relaxed form of the rules for doing Object Calisthenics. Unless you’re solving the code problem using a paradigm that is not object-oriented, in which case you are truly awesome and you will stand out from other submissions.
Whatever you do, keep your code submission simple.
Developer Minutes 
If you're so inclined to handle all possible failure scenarios, go ahead.
I'd say the rules of simplicity (while making sure the input expectations are met) should apply here as well.
Why do you see error handling as an exception to the Agile principle of not thinking too much into the future?
You're right. Simplicity wins here as well. If you assume perfect inputs, say so in the README and move on.
However, sometimes I think that 90% of writing good software is about providing a good error message when things fail. So if the candidate agrees with that statement and handles error cases when parsing inputs, then I'm inclined to forgive the added complexity.