Monday, March 17, 2008

Followup: which skills to list on your first resume

Over at techinterviews.in, they've picked up on my recent series about writing your first resume and posted some good comments, including:
There’s nothing like picking a language or operating system or database management system that a candidate listed towards the end of his resume, and having an interviewer, who’s the expert in the field (”Ah! So you did Nintendo DS assembly programming, too! Let’s discuss this in detail!”) then discover that the knowledge of this listed tech is, to say the least, limited. It makes the whole resume look like a creative writing projects, the aim of which is to specify as many buzzwords as possible.
I do advise undergrads to be a little liberal in listing technical skills, and I want to take the time to explain that a more clearly.

Here's an example from my own experience. One of my undergraduate research jobs was with a research group studying human cognition, primarily via a cognitive modeling system built in LISP. I joined the group in my sophomore year and stayed on through graduation, during which time I wrote several hundred lines of LISP glue code to manipulate my models and experiments. By the time I was interviewing for jobs, I was very comfortable writing complex LISP code and tackling problems with a functional approach. However, I knew very little about the overall design of the language or some of the important big concepts like CLOS. But I still listed LISP on my resume.

I recently had cause to write some LISP code for the first time in 10 years, and I was still able to work effectively in the language. But I wouldn't even consider listing LISP on my resume these days, because it's far outside the core of my expertise.

On the other hand, my first research job in college involved writing a mix of Fortran and C code for a parallel supercomputing group. In the year or so I worked with that team, I probably wrote a few hundred lines of Fortran code, and it was ugly. In my senior year, I left Fortran off my resume - if someone had asked me to write even a line of Fortran code, I would have been helpless. In any event, I knew I didn't want to work for a company that would be excited by my experience with Fortran.

In brief, when someone fresh out of school lists a particular technical skill, my expectation is that it conveys less expertise than when someone 10 years out lists the same skill.

If you really want to be precise in listing technical skills, the best approach is to quantify your level of experience. Some people take the straightforward approach of listing the number of years they've worked with a technology. I find it more useful to communicate a self-assessment of your skill level, using phrases such as "expertise in ..." and "familiar with ..."

But if you're just coming out of your undergraduate program, list anything where you think you can speak intelligently about the technology. If an interviewer asks a question that goes beyond your expertise, admit it, and offer a quick description of how you've used that technology and what areas you're best suited to answer questions about.

Wednesday, March 12, 2008

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

Hopefully my first two posts in this series have given you a good idea about how to start your resume, and what to emphasize and downplay. By now you've got a good draft, and you've had it reviewed by a number of friends. What's next? Take a pass over this list and make sure you're not committing any cardinal sins.

Some resume mistakes are so bad that you must never commit them. Please. The ones that always set me off are:
  • Multiple pages. I've have reviewed hundreds, if not thousands, of resumes, and in all those examples I have seen only one multi-page resume come with a strong candidate behind it. All the other ones, the ones where people list every class project, or every club they've been in, or the names of all their teachers in high school? Worthless. Take the time to distill your education and experience into the points that can be expressed in a single page of text. If you can't get it down that far, hand a draft to one of your editors and ask them what's least interesting.
  • Spelling mistakes. See my earlier comments about having several other people read your resume before you share it with any companies you're interested in. When I see a really egregious spelling mistake, I will discard the resume completely.
  • Using the Microsoft Word resume template. First off, the template just doesn't look that great, and second, it sends the message "I just put this together in five minutes because that's about how much I care about your company. Please pretend not to notice." I accept that page layout can be hard, but if you can't create something that looks decent, ask a friend for help. The layout for my first resume came from a good friend who actually has a talent for these things, and I used it successfully for the next several years.
  • A non-CS undergraduate degree followed by a CS Master's degree from either (a) a no-name computer science program, of (b) a top-tier school that is known to be a diploma mill for anyone with the money to buy a degree. I'm not naming names here, but you know who you are.
Lastly, I just want to touch on the long-standing debate about whether or not to include an "Objective" at the top of your resume. In the modern era, most resumes are submitted directly for one or a small number of job openings, so I'm going to assume that your objective is to get hired for one of those positions. Including a comment in your resume to tell me you want a career like the one I have to offer you only wastes space that you could be using to tell me more about your background and expertise. I say skip the objective, but you can decide what works best for you.

Thanks for reading this far. If you found this guide useful, please leave a comment.

Tuesday, March 11, 2008

Please keep your laptop open in meetings

Jeremy Zawodny has mixed but generally positive feelings about not having laptops open in meetings, but I think he's actually going after the wrong point. What you really want is a "no distractions in meetings" rule - working on email, thinking about your vacation plans, or what you'd rather be doing at the time - are all detrimental to the effectiveness of a meeting.

If you can avoid distractions like email or feed readers, a laptop is an invaluable tool in making a meeting more effective. Almost every useful meeting I sit in these days involves constant references to documents stored in the cloud, real-time scheduling for follow-on conversations, and back-channel talk among participants. All of these, obviously, require a network-connected laptop available throughout the meeting.

Allowing people to keep their laptops open requires a certain amount of trust; namely, you're trusting that people will use their laptops to further the goals of the meeting, not to be virtually elsewhere while others are counting on your input and feedback. But a laptop is a great tool; let's not throw out the good with the bad.

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.

Sunday, March 09, 2008

The CS undergrads' guide to writing your first resume

Continuing on the theme of bridging the gap between an undergraduate CS degree and a career in software development, I want to talk today a little about resumes.

What a Resume is Good For

The most common mistake people make with their resume, young and old, is to write a resume that makes the case for hiring you. No smart company is ever going to hire you on the basis of your resume, so don't even try. Your goal is to have me read your resume and think, "Hey, this person sounds really interesting, I should set up a phone call with them." And that's it. If you want to, you could really stop reading here - once you understand the critical purpose of a resume, everything else is just details. So let's really drive the point home: a resume's only purpose is to get someone, anyone, to read it and be interested in you.

If you're still with me, let's start things off with...

How to Write Your First Resume
  1. Put your name and contact information at the top of the page, in a font larger than anything else you'll put on the page.
  2. Start a section called "Education", and include:
    • the name of your college or university,
    • the name of your degree program,
    • and your GPA. Please consider your GPA to be mandatory. Your career counselor will likely advise you not to list your GPA if it's below some threshold (usually a 3.0), but please go ahead and list it anyway. It's easier for all of us if a weak GPA can be weighed against all the other information on your resume at the same time. To put it another way: if you have a really strong resume with no GPA listed, you leave a big gnawing unknown out in the ether. If you at least list your 2.8 GPA and then go on to tell me about a whole bunch of awesome stuff you've done, I can make an informed decision about whether to proceed; if your GPA isn't on your resume, I'm likely to pass it over without ever talking to you.
  3. Next, list the most interesting and challenging CS courses you've taken. You're shooting for 3-5 here, and if they don't have names I'd intuitively understand (ex: "How to Think Like a Computer Scientist") please do me the favor of translating them ("Discrete Math and Algorithms").*
  4. Create a section called "Experience" and write down everything you've done that resembles a non-academic programming position. Personal projects, summer internships, research projects, everything can go in here. This is the meat of your resume, and where you're really likely to hook me into wanting to learn more.
  5. Create a section called "Technical skills" and list every language, operating system, database, and development platform you're competent in. This means leaving off the stuff that you experimented with that one weekend freshman year. I want you to be able to tell me some of the ins and outs of any of the items in this section. I don't expect seniors in college to be experts in anything, so don't be too conservative, but you want to avoid setting off my bullshit meter [addendum].
  6. Finally, in a section called "Activities and Awards", list the most important activities you've participated in and awards you've received. This should be much shorter than your "Experience" section, but don't leave it off completely.
  7. Find someone to read your resume and give you fair and honest feedback. Start with a classmate. If you can, find a recent alum from your program and ask them to review it. Show it to your advisor. You can't have too many people read and comment on your resume. Listen to what they say, and incorporate their feedback.
Still with me so far? Great! Keep reading for basic tips on what to emphasize and the cardinal sins to avoid that will take this recipe and turn it into a winning resume.

* Real example taken from the Carnegie Mellon undergraduate curriculum circa 1996.