One of the things that struck me after joining Justin.TV is just how hard it is to interview at a company. For reference JTV give you 4 hours of interviews and we score each interview on a scale of -1 though 2. -1 pretty much vetos the decision to hire the candidate, 0 is "meh", 1 is "OK", 2 is "I want this person on my team". By the end of the first two interviews you must have scored 1, and you must keep this average across the next two, we round down; thus if your first interview is 0, the second 1, you must score 2 in your next.
I learned from Nathan Marz that keeping people chill increases the chance that they can think clearly. Panic and frustration is just noise when trying to assess someones calibre. I like to think I have a good handle on this in general.
Before getting to the interview stage there are two other stages; 1) problem solution, 2) phone screen.
The phone screen is much the same as an in person, particularly thanks to tools like Skype and collabedit / etherpad.
I'm always so shocked by how clear it is that people are panicing in their problem solutions, however. We do not put any time limitation on the candidate[1], you are at your behest to take as long as you wish to implement the best solution you can. You have all the time in the world to read, refactor, submit test cases, etc. Very rarely do people gold-plate their answers, I've had less than 1% of the solutions I've received contain a test case; which, frankly, leaves me gobsmacked.
It is fair, while creating something for the first time, that you do not create test cases, build processes, etc. But before you submit code for peer review you should make sure you would stand behind it, maintain it, pontificate about how great it is. If you do not have the basic code-hygeine bases covered how do you expect me to be able to rate your ability as a developer?
Of course, none of these concerns are important in an in person interview thus you can be "lazier' than you would in real life, but the code you send us is real life; I want to run it on my system, a co-worker may want to run it on their system, does it work on both? Which systems? Did you include a README telling us which systems it runs on, which it has been tested on, how to use your build script?
The worst thing you can do is not take my time seriously, our users need my time, and when I'm reviewing your code you are taking me away from where I want to spend my time. Make it a pleasant experience for me... please.
If you like taking code seriously, and producing high quality work, then chances are we'll like you and you should apply to us :)
[1] - not entirely true, we have recently started putting a time limit on one of our positions - however we feel speed is a very important part of this position so it reflects what we expect from the candidate.