Programming Assignment - what's important?

First, breaking in is hard. You are non in a vacuum. It is entirely possible that you did everything right and they still chose not to hire you.

I would just do a normal code review: Does it work? If it doesn't work then nothing else matters. Next, what kind of problems are there with the code? Does it potentially follow null pointers? Does it potentially divide by zero? Does it potentially break numeric limits? Did you use magic numbers or named constants? Is everything initialized to sane values? Are any resources leaked? Etc., etc.

If you have to focus on anything, that one thing should be maintainability. Can someone else come in and tinker with the code safely? The answer should be yes.

Don't let the first interview get you down. You will probably need to interview at multiple companies before you eventually land the job. That is normal.

Good luck on the job hunt.

Thanks for your advice! I mean, most of it is common (programmer's) sense, but under pressure it could be easily neglected...

The very first thing you should focus on is making sure you understand the requirements -- it's all too easy, under pressure, to either miss a key detail, or fill in details left unclear based on our own experience. Read the requirements clearly and ask if anything is unclear to you (explaining what you understand, and asking specific questions based on that). The requirements may be functional, engineering (solution structure), algorithmic (time and space), or otherwise.

How you approach the solution is largely based on your own style -- but you want to think about simplicity, maintainability, extensibility, and performance, to name a few.
Its acceptable to prototype and throw away code too, providing you can do it and complete the assignment in the allotted time. As Frob said, maintainability is probably the one key thing if there were only one; alas, its always a balance, so a solution that achieves great maintainability at great cost to simplicity or performance is probably not the solution they are looking for. In the end, their judgement is going to be subjective, so don't get so caught up on any one aspect that it begins to cost you time.

And don't forget to reserve time to test your solution.

If you should find yourself with extra time, go back and make sure you've commented correctly and thoroughly, and perhaps provide some light documentation -- outline the approach, discuss your design options and decisions, talk about performance and storage requirements. Even if they don't ask for this last step, it will be valuable as an orientation for reviewers and demonstrate how you communicate technically, so do it anyways, time permitted. Keep it brief, but no briefer than need be. If you can give the impression that you can communicate technical information in impromptu meetings around the water-cooler, its a very desirable quality.