What should my “code sample” look like? [closed]

Question

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!

Answer 1

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.}

Answer 2

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.

Answer 3

• 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.

Answer 4

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.

Answer 5

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?)

Answer 6

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.

Answer 7

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.