Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Is bringing printed code or code on a USB to an interview a good idea? If so, what kind of code should I bring. Should I avoid big projects and just show small snippets which show off my skills?

share|improve this question

closed as off-topic by gnat, GlenH7, durron597, MichaelT, Snowman Jun 7 at 16:09

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – GlenH7, durron597, MichaelT, Snowman
If this question can be reworded to fit the rules in the help center, please edit the question.

No. What a company can do is give you a take-home exam after an interview, and then have you back in 2 days or so to explain what you did and why. – Job Jan 19 '11 at 16:47

9 Answers 9

up vote 14 down vote accepted

Rather not. I would only do this when explicitely requested, and of course you can't bring code that's in any way confidential, which usually applies to everything you wrote in your previous job, so you are basically restricted to code you created in your spare time. (Most interviewers would immediately have you escorted to the door if you come with confidental code from your current employer...)

Anyway, as the interviewer, I'd rather want to see you write code during the interview, so I can be sure you are the one who has the skills. It's just too easy to have good friends help you write a most impressing piece of code, and memorize the explanations.

share|improve this answer

I think it's a great idea! It's a pity code reviews are not done more frequently as it is one of the few ways of recognize good programmers (except actually having them code something). Looking at someone's code you pretty quickly get a sense of how good a programmer is just because how much "cleaner" their code is.

If I was interviewing I would be looking at two things that probably would be good to cover in the code you bring

a) The quality of some implementation/method/algorithm. Show some code that you found especially elegant

b) The overall architecture of a larger program. How has the programmer handled dependencies, can he explain the design decisions he's made

The goal is not to go through all code so it really doesn't matter how long the code you bring actually is, but what you chose to highlight about it.

share|improve this answer
There's always the problem of actually knowing that the code is written by the interviewee. In that sense, maybe a code review of someone else's code could teach you as much, if not more - as the interviewee won't have been able to prep in advance? – Benjol Jan 19 '11 at 7:59
I wouldn't think that was much of a problem, since you're judging the person on the ability to explain his code and thinking. That's pretty hard to do if it's not your own code. How can you explain something well that you don't fully understand? – konrad Jan 19 '11 at 8:16
Let's not forget the potential (or probability) that the piece you wrote is the IP of your former employer (unless it's a side project or personal piece written) and I'd avoid crossing that line as much as possible, innocent or otherwise. – Brad Christie Jan 19 '11 at 8:45
Brad, that's a good point. Normally you're not allowed to retain copies of work done as a consultant so it might be hard to use code like that. Another reason to hire programmers who work on pet projects! :) – konrad Jan 19 '11 at 8:51

A variation on this is to provide the interviewer with the URL for the repository for some open-source project that you've made a major contribution to.

share|improve this answer


Unless you are scheduled to give a reasonable length presentation in your interview, the kind of code you have the time to show and they have the time to appreciate; cannot be representative of your skill, regardless of where you are in your career.

If they want to see evidence that you are a mature software developer, then that won't be found in the size of program that you can effectively walk through in the AOB section of an interview.

If they want you to demonstrate that you can program at all, they'll have a proper test, or get you to do something small like a linked list on-the-spot. If you bring along a linked list implementation on a USB key, they have no idea how much of it you copied from a book; whether it took you 10 minutes or two weeks; or whether you had to ask stackoverflow what a pointer is.

Moreover, what would you show? Clean, well-written code that is easily understandable is boring. Your interviewers won't sit there marvelling at how clearly they can grasp the intent of your snippet, they will be wondering why you consider it to be the jewel in your crown. On the other hand, Imagine you invented something clever like Duff's Device, and wanted to show that off. The interviewers would likely consider you an enemy of readability.

share|improve this answer
Clean, well-written code that solves a tricky problem can be extremely interesting. And if the interviewer doesn't think so, it tells you one of two things: either you're not at the level they're looking for, or they're not at the level you want for colleagues. Either way (and hopefully the discussion would highlight which), it's time to look somewhere else. – Anon Jan 19 '11 at 12:15
What I mean is that clean, well-written code that solves a tricky problem makes the problem appear considerably less tricky, thereby making the code itself appear considerably less interesting. – Paul Butcher Jan 19 '11 at 15:31

The code you show should generally be small enough to be talked about within 5 minutes, and the code should take up no more than 2 printed pages. Even if it's just a method that you wrote to parse phone numbers from a phone book, it's useful.

share|improve this answer

If you want carry the design. Don't carry the code. More than seeing the cleanness, the interviewer will start pointing out the errors. There certainly would be (many) errors (which you haven't thought of) if the project is some high school project. And if it is some company code, it is illegal to carry the copyrighted code and show to other people.
Showing the code you have already written may not carry much weight if you fail to answer the questions asked by interviewer. And if you don't carry it, then also there are no -ve points. So why bother.

share|improve this answer


Any fool can write code that a computer can understand, it takes a great programmer to write code that a human can understand.

For that reason alone you should show off

share|improve this answer
If you code is actually human understandable. Otherwise, don't :) – Mchl Jan 19 '11 at 14:55

If you have a piece of code that is particularly interesting, then by all means bring it (assuming, of course, that it's not protected intellectual property). But don't force it on the interviewer. If s/he is interested in looking at your code, s/he'll ask if you have anything to show.

Be prepared to explain why it's interesting, and better, what you'd do differently in the future.

share|improve this answer

If you have done any open-source development (either business or personal), I think this would be a great idea. I sent code snippets along with the application materials for the job I currently have, so I'd venture a guess that it worked out OK for me. Make sure to respect confidentiality/copyright and give attribution to others who were involved (if it was a collaborative project).

share|improve this answer

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