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