I've just had quite a good phone interview (for a CakePHP-related position, not that it's especially important to the question). The interviewer seemed to be impressed with my resume and personality. At the end, though, he asked me to email him a code sample from my existing work project, "to check you're not secretly a terrible programmer, ha ha!"

I'm not too worried that my code can't stand on its own two feet, but I'm very much an intermediate programmer rather than an expert. What obvious pitfalls should I make sure my code sample doesn't fall into, in case they rule me out on the spot? Secondly, and this is probably the harder part of the question to answer, what features in a code sample would be so impressive that they would instantly make you much more favourably inclined towards the programmer?

All ideas or suggestions welcomed!

  • 2
    Were there any requirements on the code sample to send? Seems rather pointless, anyone can copy/paste beautiful code from the web. Unless they're trying to weed out people who can't even get that right... Feb 23, 2011 at 22:29
  • 5
    Just for kicks, you could send a Perl script that's in the shape of his/her name... ;) Feb 23, 2011 at 22:32
  • 2
    @thesunneversets: So I guess the absolutely gorgeous source code from your personal projects are out... ;) Seriously, this could be easily faked. And is your current employer OK with you giving out a representative sample of your source code? Is it OK if some of the code was written by a co-worker (maybe the file's gone back and forth between a few people over time)? Feb 23, 2011 at 22:36
  • 2
    The ethical implications are a little worrying... but only a little. I don't think I'm falling into an industrial espionage trap. As for co-workers, alas only two people have ever gotten their hands on this codebase, and the other guy's code was a big mess, so I'm pretty much on my own! :) Feb 23, 2011 at 22:43
  • 4
    @thesunneversets, providing your employers' code is not just unethical, in many places it is illegal. Do not do that.
    – HLGEM
    Feb 23, 2011 at 23:04

7 Answers 7


I'd like to see Clean code:

Clean code: Software code that is formatted correctly and in an organized manner so that another coder can easily read or modify it.

That means:

  • Functionality - Some simple bits of functionality that are non-trivial (a bunch of getters/setters wouldn't show that you know anything)
  • Consistent, clean style - Popular or at least common casing, indentation, spacing and bracket styles
  • Good Naming - Quality names - don't use i unless it's the only increment value. Don't use nonsense variable names.
  • Other attributes of Clean code - Good practices on error-checking, conditions, loops, convenience methods or utility methods, and good separation-of-concerns (between methods). And this is a good time to be 100% DRY - no repetition!

You want to send them something that is complex enough to be interesting but clean enough that a good developer can nearly immediately understand what it's doing.

Some of the comments above seem concerned with how easily this could be faked.* If you want to protect against this, then possibly send a quick description of the purpose and history of the code in the email.

* At the very least if the interviewer asked about past projects up front, then asked you for a sample from this project, and asked what required you to write it or how it evolved, I think the process would be pretty liar-proof. I think most candidates who would lie are going to show problems in other areas, anyway.

  • If you ask the person to explain the code and they can't they didn't write it or they adjusted someone else's code in maintenance without bothering to understand it first. Amazing to me how many people I've interviewed through the years who can't explain their own sample.
    – HLGEM
    Feb 23, 2011 at 23:03
  • Add some comments in case your marker hates clean code.
    – Ewan
    May 11, 2015 at 10:44

When I was looking for work, I solved a bunch of ACM programming contest questions, in several different languages, and use those for code samples since then. I think they made good code examples because:

  • They solved challenging problems
  • The problem didn't require a huge amount of context, plus its easy to get the questions
  • The code written doesn't have any IP risk associated with it.
  • Each problem can reasonably exist in a single file, and often not extremely long, so it should be easy for anyone to compile, and test your solution, and can use the test data from the questions.
  • Shows you can break down a complex problem into smaller pieces.
  • If you are asked about how any aspects of your solution works, it gives you a great opportunity to demonstrate you know what you are talking about, especially so if it's many years old but you can quickly decipher whats going on.

And then, the code you create should be clear, consistent, easy to read, and easy to understand.

And lastly:

  • It's worth solving them just for fun, and is good practice.
  • This is a great solution. I am going to do this. Were there any specific questions you liked best?
    – zkent
    Feb 23, 2015 at 14:56
  • 1
    As a comment from me, I think that having a single-file code sample is not necessarily a great idea unless you are applying for a position for optimizing code or algorithms. The code certainly shouldn't be huge, but it should be somewhat representative of what you can actually accomplish (e.g., if you can write good OO code and split code into modules reasonably, it should demonstrate that).
    – Namey
    May 10, 2015 at 21:00
  • It should compile/interpret error and warning free at the highest strictness level.
  • It should not be boilerplate code you write every day. Make it unique and interesting so it is obvious you didn't copy/paste it.
  • It should have some interesting design decisions with comments explaining how/why you made them.
  • Aim for no more than 2-3 pages printed out.
  • It should be in the language you are applying for.
  • It should not make my brain hurt when I read it the first time. Have a friend look it over, or post on codereview.

Well, if I were interviewing you, I'd like to see your code.

Clean is good, problem-solving is good, but true code is better. A good programmer knows when he/she was scammed by another programmer, so the confidence could go down.

Reading another person code is like dancing having sex: you know when it is the real thing, and if the other person is faking it, in the end a disaster will occur. (just realized real nerds don't know how to dance)

Just trust yourself and your coding abilities. Unless you really know your interviewer, you cannot anticipate what he expects from your coding style/skills.

  • 10
    I love that you don't think nerds can dance but you are confident of their sexual prowess! :D Feb 23, 2011 at 23:30
  • Nah, I just saw too many disasters myself... :)
    – Machado
    Feb 24, 2011 at 1:54
  • At my school, the only people who show up for social dance classes/balls are engineering majors.
    – Eva
    Feb 4, 2013 at 18:23
  • You should replace sex with some gaming reference to be more accurate :)
    – zkent
    Feb 23, 2015 at 14:55

Also be very careful that it is NOT code from your current employer (They own it you don't and I guarantee they will not like you sharing it.). Take something you are proud of and rework it on your own to not be employer specific (get rid of any references to their database tables or servernames, etc). Whatever you do don't submit code that has mistakes or is a poor technique for the type of code it is (I would probably reject someone who submitted a cursor when a set-based operation would be simpler and perform better when reviewing SQL code. There are similar techniques for other languages that are there to solve one relatively rare problem problem that can be used for other more common problems but are not the best choice for those other problems. Did that sentence make sense?)

  • I agree, completely reworking it so it's no longer contains any employer-specific information seems like a good idea. Ethics are important - thanks for the tip! Feb 23, 2011 at 23:11

I would second the post from Renesis about clean code, but would add to the list supplying quality and well-documented unit tests to the code you submit. A good programmer should be writing unit tests for their code.


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:

  1. 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.
  2. 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?
  3. 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:

  1. Style: The code should be clean, consistent (follows some established guidelines), and well-documented.
  2. 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.
  3. 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.

  • I will also note that, in full disclosure, I provided a code sample to the graduate school lab where I was accepted for a PhD. This code sample was the full code for an autonomous robot (5-10k lines), with a particular three files singled out. Documentation was respectable, but not pristine. If I had to do it over again, I probably would not have brought a printed version of the code to my on-site interview (could have brought 100 pages saying "ROOKIE MISTAKE" in big letters). I did receive a full fellowship, so it wasn't too much of a faux pas. Moral: Too much >= too little.
    – Namey
    May 10, 2015 at 22:16

Not the answer you're looking for? Browse other questions tagged or ask your own question.