I don’t usually ask for a code sample, but I do accept them if they are offered. I don’t ask for them because the code samples I have received have been disappointing and perhaps do not represent the potential of the person giving them to me. The biggest problem is that they weren’t written to be shown and are usually just plucked from some project as part of the job application.

It’s extremely hard to take a piece of a large project out of context and make sure that it’s self-contained and interesting. More experienced developers have the added problem that a lot of the code they have written is proprietary, and they cannot share any of it. Generally, side-projects and school projects just aren’t written with showing it at an interview in mind, and I don’t think it’s fair to put the interviewee on the spot by asking for it.

When I get them, my best use of code samples has been to use them as a jumping off point for an initial line of questioning. I try to identify a small chunk, like one function, that I think can be improved. I tell the interviewee my problems with it (like a code review) and ask them to be prepared to improve it when we meet.

But, I’d like to do a lot more, and to make it more likely that I’ll get good samples, I’m going to document what I’m looking for and hope to hear some feedback about it.

1. Let’s stop calling them code samples. They should be prepared portfolio pieces. That means working code that I can run, and access to all of it. Probably the best thing is a running website and a github repository. If the software is hard to run, then a video walkthrough or screenshots are acceptable substitutes.  
   
2. I only want to see code that you intended to be read. I understand that you might have taken short-cuts on your side-project to get it done, and that your Junior year sudoko solver is a hacky mess. Don’t show me those – either fix them for review or write something small that you want to be read as an example of the work you will do if hired.  
   
3. I could use an orientation. I need a starting place. The bigger the project, the harder it will be to jump in and take a look around. Give me what you’d give a new contributor.  
   
4. You can’t have a total blank on design. I am not looking for designers, and so I am prepared to give you a pass on this, but it can’t be horrible. Just get a free template or use ultra-standard GUI guidelines. Make it easier on yourself by keeping the project small.  
   
5. The repository is part of the review. I am probably going to look at commit comments and the progression of the project.  
   
6. I need to know what part you did. It’s probably better to send solo projects, but if your best piece is a collaboration, then I need to know what part you did.  
   
7. I’d like a writing sample as well. This could be the walkthrough, the project description, or your blog. This is an important part of your portfolio, and just as important as your code.  
   
8. The right size is probably about two week’s worth of work. If you don’t have a public project, and are thinking of preparing a portfolio piece, it doesn’t have to be a giant project.  I think something with a dozen or so code files is about the right size to review. If you are showing me something much larger, then point out a part that I should focus on. 

I think my process will be the same to start. I will look for a part to code-review and give it to you beforehand. 

What I’m hoping for is that these prepared pieces will offer much more insight into the person I’m interviewing and allow for a much deeper line of questioning.

I’d love to hear any any experiences on both sides of a code portfolio review. What worked, what didn’t. If you have something like a code portfolio prepared, I’d love to see a link.