The CS undergrads' guide to writing your first resume, part 2

Ideally yesterday's post gave you the basic structure for your first resume. Today I'll give some more details on what to emphasize, and what to downplay if you want me to read your resume and call you for an interview.

The Top Things I Look For In Your Resume

• A degree in Computer Science. I see lots of resumes from people with degree names like "Information and Decision Systems" or "Technology Management". I won't discount the value of those degrees, but for the kind of software development I do, my experience has been that a rock-solid understanding of computer science is the cost of admission. I'll always award bonus points for a minor or a second major that reflects to your interests and could be applied in your work.
  
• A good GPA. For many schools, especially the top-tier schools, this means roughly something over a 3.5. I know you think college is hard and I don't understand your courseload and blah blah blah, but the fact of the matter is, a large part of your success in college is determined by your ability to manage and schedule your time and your work. If you had a B average, my first hypothesis is that you can't manage your own time, and transitioning to the professional world isn't going to make that problem magically go away.
• Did you do more than just go to class? This is where you really set yourself apart from every other graduating senior with a degree in Computer Science. If you think you went to college for the classes, you really wasted the other 158 hours of every week.
• As a follow-on to the last point: did you demonstrate leadership talent outside of class? Most people shouldn't be President of Student Government, but you can be Vice President of Students for the Exploration and Development of Space. Heck, I was. I'm not saying that I only want to hire leaders, but I am interested in people who are willing to step up and volunteer their time and energy to do something larger than themselves. These are the people who see a problem and attack it, not just complain about it. Even better than taking on a volunteer leadership role is taking on an elected leadership role - it demonstrates that other people look to you as a leader.
  
• Interesting projects. For me, if I read a project description on your resume of something I don't know how to do myself, I'll want to talk to you just so I can learn more about that project. Translation: while you're in school, look for opportunities to do hard projects. The homework assignments in your intro CS class aren't going to cut it, and the final project in Operating Systems probably won't, either. Get involved in a research group, or start something with your friends, but set out to tackle something difficult. Great big warning: if you list a project on your resume, be ready to answer questions about any aspect of it. Any hint of bullshit on this point will taint the outcome of your interview.
  

I appreciate that this list is completely useless if you're about to graduate with a C average in Database Systems, having done nothing outside of the classroom except get high. Sorry.

Also, and this is not critical, but please, pretty please, use a format that will work on my platform. Since you have no idea what platform I'm using, go with something nice and portable. PDF is still the gold standard, though I'd be very impressed by anyone who sent me a resume by sharing a Google Document. Plain text works as well, though it severely limits your formatting choices. Whatever you do, just stay away from MS Word - almost any fancy formatting you do in word will not translate correctly into, for example, a Linux-based word processor like OpenOffice. I have a fixed amount of time to review your resume, and if I spend most of that time piecing together bits of text that wound up splayed across several pages, I'm probably not going to notice that hidden gem of a project you did sophomore year.

I've found a common problem on resumes is to really drum up things that turn out not to be that important. This is based entirely on my experience on the observed correlation between background and impact as an engineer. To wit, here are ...

The Top Things I Don't Look For In Your Resume

• An extremely high GPA. Once you go beyond the 3.5 - 3.75 range, there's a leveling effect; in my experience the kid who got a 4.0 is just as likely to be good at writing software as the kid with a 3.75.
  
• A top-tier school. There are a huge number of benefits to going to one of the three or four "best" CS schools in the country, but they seem to have little predictive power in the quality of the work someone will do professionally. I've known too many screwups from MIT and CMU, and too many rock stars from lesser-known schools, to care too much about where you got your degree.
  

Caveat: Sure, if you went to CMU, that's an added bonus for me, because I know we immediately have some common background and we can swap stories about Mark Stehlik or late nights spent in Wean. But that's still not going to get you a job, and if the rest of your resume is weak, it might not even get you an interview.

• Some minor contribution to some minor open-source project. Open source is great, and as an undergrad, contributing to an open source project is a great way to get some exposure to real software development. However, your two-line contribution to libsecondlife, correcting the spelling of "Linden" in the comments, is really not going to get me excited, so please let's just skip it.
  

Obviously none of the items on this list should be considered a negative; I'm just saying that don't waste a few dozen words extolling the virtues of MIT, or trying to convince me of the quality of your non-MIT school. Tomorrow we'll cover the real pitfalls that destroy a lot of otherwise strong resumes.