Let's start with some meta-advice. You should take any and all resume advice with a grain of salt. Every person who has ever read a resume or conducted an interview has their own opinions on what they want to see. Instead of telling you what you should do, I'll tell you what I find myself doing and I'll let you figure out which bits are valuable.
Over the last year or so I've spent a fair bit of time looking at resumes from both undergrads and new grads for full-time entry-level positions and internships for our small software company (we do face recognition). First let me say that we don't much care about which languages or technology you claim you know. We are firm believers that smart people who show a history of initiative will rapidly get up to speed on our technologies of choice. The important lesson here is simple: buzzwords aren't as valuable as programming aptitude and a history of initiative (or rather, being smart and getting things done).
I took pretty good notes (especially after the career fair I attended as a recruiter) about whom I was impressed with. I noticed a very obvious pattern emerging. Let me tell you exactly what I look at your resume to find:
Things that I really want to know about:
Things that will also help:
Things that probably won't help:
Things that will hurt you:
Either go find a professor or a club that will let you work with them or find an open-source project and get involved. And the deeper you get, the better it looks. Getting involved in a shallow enough capacity to slap it on your resume will get you in the door, but you'll fail gloriously come interview time. If you can talk with me for an hour about the time you had to choose the correct algorithm for the memory vs. speed trade off for your ping-pong playing robot, you'll have my vote.
Does it matter what language or technology the side-project uses? No! We hire people to do low-level computationally-intensive multi-threaded number crunching. But if some college kid walked in who has built a bunch of his own rich internet web applications, knew several web frameworks, and contributed to a variety of open source projects -- and he really wanted to work here -- I'd hire him in a heartbeat. Why? Because the kind of person who wants to program on his own time for his own purposes is the kind of person that makes a good engineer. Passion is three quarters of the game. And most of the rest is made up by initiative and determination (people who "get things done").
I am really passionate about programming and have done lots of work on big projects outside of class!Great. You're hired.
I am really passionate about programming but I don't really have anything to show for it.First, don't feel bad, many people fall into this category. I did. You guys are passionate about programming but have never gotten seriously involved in anything deep enough to put on your resume. Listen closely though: you guys have not one, but two problems. First, it's hard for you to prove your passion on your resume and second, even if you can convey it, you've shown a lack of initiative. Your resume's goal should be to distinguish yourself from the horde of passionless people who are your competitors.
I suggest you strongly focus your resume on your favorite class projects and try your best to put at least one "on your own" project on the resume. Even if it wasn't terribly serious (it belongs near the bottom, in that case).
I don't really like programming on my own time.I hope you know java! (Ok, that was a cheap shot.) Nothing really changes from above, however. You should focus your resume efforts on the classes you took and your favorite projects . You also might want to consider if software engineering is the correct profession for you. There are plenty of related fields that you might enjoy more (like a sales engineer, or technical writer).
These items are worth mentioning towards the bottom but they should never be the focus of a programming resume. If half your page is filled with your various non-technical jobs, each of which has several line items of responsibilities, you are doing it wrong. Keep those items short and sweet and use the extra real estate for technical matters, even if you have to use in-class projects.