As one opinion from someone who does request code samples when evaluating candidates, there are a few high-level features (content of the code) and a few low-level features (structure of the code). High level features:
- Identity: The flavor of the code. If you're billing yourself as a UI/HCI coder, I want to see a good look/feel for something visual when I run it. If you're a DB builder, I want to see something interesting with data representation or analysis. The sample should be something you're proud of. If you don't have at least one of those, you have no identity.
- Maturity: Do you shift strategies for different problems? Are you solving interesting problems? Would the code or approach be easy to extend to a similar problem? On the converse, do I feel like I am looking at a member of a cargo cult commune?
- Communication: Does the code easily explain what it is doing and why? This does not mean the code needs to be simple. In fact, it is a bonus to make complex code easy to understand.
The low-level aspects are simpler:
- Style: The code should be clean, consistent (follows some established guidelines), and well-documented.
- Packaging: There should be at a minimum a short readme, a runnable version, and runnable tests. The readme should tell me how to run the latter two, as well as why you are demonstrating this particular code sample.
- Language(s): I typically ask someone for a sample in the language for the position, as well as the one they feel strongest in. Gives a good idea of a person's current ceilings.
For a good candidate, I expect a sample to be either: A) A bulletproof small sample or B) A good part of a larger interesting project (e.g., a module from a Github personal repo). I expect them to be personal projects or academic projects. If they send one from a paid project, I expect a note that they were given permission to use it. If I don't get that note, I will cut them from the candidates (weak candidate) or ask them about it during the interview (strong candidate). Not having permission would be a big red flag (probably insurmountable). For an advanced candidate, I expect a disclaimer noting that some of their best source samples cannot be shown because it was done as part of their job. However, I then expect a gushing testimonial of why they are proud of that unshowable design and how they love it like a child.
Finally, as much as some people chide that "Oh, someone could just get a code sample from the internet," the counter-argument is that most people who do not understand good production-quality code also do not understand it when they see it. Besides, one can always Google a distinctive line for the code to check. Also, at best, stealing code will get a candidate to an interview where they embarrass themselves ("So why did you do it this way...?").
As a last note on code from prior employment: Just don't. From an HR standpoint, asking for code from previous employment is inappropriate and a red flag about the company. You would both have legal liability (i.e., you could both be sued) and it shows that they have no idea what they are doing. Code done for a prior employer should never be given unless the code is already publicly-available or you have explicit permission from that employer. Worse, in a big company, your direct boss may not have the power to give you permission, so have fun with the legal department in that case? I'm sure they'll be overjoyed to expose their IP for an exiting employee.