How to prepare a code sample

In some companies asking the job candidates to provide code samples before the interview became a standard part of the hiring process. Here are some guidelines which will help you to avoid common mistakes, make a good impression with your code, and, as a result, get the interview.

1.Pick the right code.

Select the code which is as relevant as possible both to the technology and to the industry. Of course, exact match is not always possible, but try to avoid obvious mismatches. For example, for a position of a Java developer, Java code will be, naturally, the best. C++ or AS3 might do; Perl or Haskell will be poor choices – quite possible that the engineer who will review your code will not know these languages and will be unable to adequately evaluate it.

Do not send too much. For me, 1-2 files is generally enough to get the idea.

Be careful about sending entire projects. First, usually projects are much bigger than what I really have time to evaluate. Second, I might be tempted to build the project and run it – therefore, you have to make sure that the code not only looks good, but also runs good.

Send only the code that was written by yourself. Even if the other person's code is a part of the project, don't send it (here is another good reason not to send a full project).

Do not send trivial or auto-generated code. A class which consists only of data members and getters/setters is not very interesting to review.

2.Prepare the code

If there is a well-known style guide for your language, make sure your code follows it. It always makes a good impression and shows you as a professional, who knows and respects the standards and conventions of the industry.

Also make sure that:

• Your code has enough comments, and that the comments follow the format recommended for your language (for example, in Java the comments should follow the JavaDoc rules). The comments should include one comment per code unit (module, class etc), and one comment per function (method etc.). Reviewer should be able to easily understand the purpose of the code and get some idea how the code is supposed to work.
• There is no obvious debugging and development leftovers. Remove all commented out lines, TODO markers, unused variables, debug printing etc.
• The variables and functions have meaningful names.
• The code is formatted so it is easy to read.

If your code has a comment with a copyright statement of one of your previous companies, think again, whether you can send it. If you still want to send it, remove the copyright statement.

Remove all references to a sensitive information. Don't worry if it will make the code unusable, or even prevent it from compiling – just make sure you explained it in the code and in the comments.

3.Prepare yourself.

If your code will be good enough to get you an interview, remember, that your code most definitely will be a part of the conversation, so:

• Make sure you understand and can explain each and every word of the code.
• If your code uses some design patterns, be ready to discuss them.
• Be ready to explain how the code works.