New Graduate Programmer Resumes: Some Tips

1-Sep-2013

Mark Roulo

I am not a hiring manager, I'm a full-time software engineer (or, really, programmer, as there isn't much of an engineering discipline surrounding software construction yet). I have, however, been involved in hiring many software engineers over the years. I've also attended job fairs and hosted informational sessions at college campuses. I've been involved in countless interviews. And I've waded through resume books. I've probably screened over 1,000 resumes from soon-to-be-graduated college students hoping to find jobs.

The bad news is that most of these resumes were pretty bad and I probably missed some very good candidates. This shouldn't be much of a surprise. You get good by practicing, and very few people write enough resumes to get good at them. The good news is that I can tell you a lot about what I (on the other side of the interview desk) am looking for in a resume. With luck, you can make my job easier and increase your chances of getting the job you want.

It is worth emphasizing that my recommendations are for programmers and software engineers. I expect that much of my advice applies to other engineers as well. How well it applies to humanities students, I can't guess.

So ...

Know What Your Resume Is Supposed to Accomplish

In some sense, this is fairly easy. Your resume is supposed to get you interviews for jobs.

Which means that your resume is basically a sales brochure for you.

Your difficulty here is that your resume may well be in my e-mail in-box along with 20+ other resumes. Or your resume may be in a resume book along with 100+ other resumes. I am NOT going to interview (or even phone screen) the candidate behind each of these resumes. If you want to increase your chances of getting that interview, you need to attract enough attention to stand out from the other resumes.

So ...

Don't Be Bland or Vague!

A bland resume isn't going to stand out. Neither is a vague resume. And I'm very unlikely to interview someone whose resume blends in with all the others. It is better for your resume to stand out and have me NOT want to interview you than for your resume to not stand out at all. The reason is that different managers/companies are looking for different features in a candidate. If I notice your resume, but decide to interview other candidates, I've still NOTICED YOUR RESUME. Some other person may well notice your resume and decide to interview you. Blending in with the crowd of other resumes makes it less likely to get that interview at all.

Better for your resume to be in the top five of 100 for 10 jobs and the bottom 50% for 90 jobs than for your resume to be about 20th for 100 jobs.

It is, however, important to stand out for good reasons, even if you aren't good fit for me. A resume that mentioned that the candidate had spent some time in prison for armed robbery would stand out. But not it a good way.

Finally, you want to use enough formatting (fonts, indentation, stuff like this) that the resume flows, but not so much that the font selection draws attention to itself. You do want to use boring fonts ... these scan better when run through an OCR system. Avoid color.

Your Resume Can Be More than One Page

Most of the resumes that I see are electronic. One of the nice things about this is that you don't have to worry about different pages getting separated or lost. Which means that your resume can be longer than one page if you have more than one page of material.

I am totally fine with multi-page resumes. Really! The old guideline that resumes needed to be only one page long doesn't apply much when resumes are electronic. And more pages gives you the room to provide the details that I also like to see.

But ... I'm not going to promise to read your entire resume. I'm going to start at the top and work my way down until I get bored or decide to put the resume into one of the interview/not-interview piles. This means that the most important stuff needs to be near the top! You can create a resume with multiple pages, but the first page needs to keep my attention or I'm not going to read the other pages. Keep this in mind ... the first page has to give me a reason to keep reading!

I Like Details

Your easiest way to not be bland is to give me details. Don't tell me that you "coded a new software analysis tool in Java." Tell me what that tool was supposed to do. Tell me how big it was (number of lines of code, or number of classes, or ... something!). Did it have a GUI? What platforms did it need to run on? Did it talk to a database? If so, which one? Did it do anything with a network? If so, what?

A real-ish example (with details changed to protect the guilty) of a lack of details is:
"Worked with the SomeTeamName team in SomeLocation to build a new tool. Developed the prototype in Python. Implemented the tool in Java and used GWT for the UI."
You probably don't know what this candidate did. Neither do I. Clearly there was some Java coding and some Python coding, but I don't know how much or what was done. The GUI could be a simple dialog box, or fiendishly complicated. I have no idea.

Lets try to fix it a bit:
Over the summer of 2008, I worked with the SomeTeamName team in SomeLocation to build a new tool to track the working IQ of management in real-time. We developed the prototype in Python, and iterated with our target users, the board of directors, until they were happy with it. This took several iterations as we tried various combinations of charts, graphs and tables and animated bubbles. The final UI we shipped was simply a large GUI pane with a bright color: Redder meant smarter, bluer meant stupider. There was a user-configurable option to embed a numerical value for the management IQ in the color pane as well.

We implemented the final version in Java using Swing for the GUI library. The tool was required to run on Windows-XP, RedHat and SUSE Linux, and MacOS X 10.3 and above. We tested on all of these platforms using the Abbot testing framework.

The code came in at about 500,000 lines of code and I wrote about 450,000 of those lines. My specific task was rendering the numeric value (if enabled) and centering the color in the pane. The tool had a hard real-time requirement of 3 updates per hour, and we met it solidly.
It should be obvious that I have a much better idea of what happened from the second version.

I can ignore (or skim over) details that don't interest me. There is nothing I can do if the information just isn't present.

Now ... one "problem" with this is that you won't get as many jobs/classes/projects/whatever onto the first page. You can take several steps to deal with this:

I Like to See Complete Sentences

I have read a lot of advice on resumes and one of the common suggestions is to avoid using complete sentences. The dummies.com web site (which hosts the XXX for Dummies series of books), for example, has an article on "Five Tips for Better Resume Writing". The article starts off with these two suggestions: The idea, I think, is that short phrases are more "punchy" than complete sentences.

It is possible that I'm in the minority here, but I totally disagree with the two suggestions above.

For one thing, given a choice, I prefer hiring people with good communication skills. And this includes written communication skills. It is, in fact, not uncommon for me to get a resume with lots of non-sentence phrases (which is what happens if you follow the suggestions above) and then, near the bottom, a claim of "excellent written and verbal communication skills."

Well, you know what? You had a chance to show me your excellent written skills and you didn't take it! Resumes with complete sentences (and even paragraphs! No, really ...) are very nice to see. I'd be surprised if complete sentences on a resume kept you from getting a job anywhere.

Don't Just List the Classes You have Taken

In the first place, lots of your classmates are doing this, too. The combined result is that all of the resumes that do this tend to blur together. Remember that I may be looking at over 100 resumes if I'm going through a resume book from your campus. Having a resume that blurs together in my mind with other resumes is not going to get you an interview.

In the second place, I probably don't know much about the classes you took. "Principles of Operating Systems" can be taught many different ways and can cover lots of different details. Tell me what you did in that class. With, again, details! Did you replace the scheduler? If so, how did yours work? How was it better than the one it replaced? How big was the code? What was the context switch time? How did you test it?

This is one area where an external web page is probably a good idea.

A resume that groups courses into cohesive blocks or themes will show me the subjects that you studied in some depth (databases or operating systems? GUIs or embedded systems). You can then have a web page with one or two paragraphs on each course. I'll click through if I care.

I Like To Know What You Did

As a rule, I like to know what you did for a given project or product. Give me enough background about the project/product to understand it, but also make clear what you did on it. Again, don't be vague about this! If you didn't code the GUI, but you did code the parser, tell me about the parser. If you don't tell me what you did, I'm not going to assume anything ... which is bad for you.

The resume is also not a good place to be modest. If you did something interesting and wonderful on a project/product, let me know about it.

Unless your GPA is High, Leave it Off

You don't need to call attention to your weaknesses. It is my job to find them. If your GPA is low compared to your classmates, don't call my attention to it. Because of grade inflation at American universities over the past decades, it can be difficult for me to know what a good GPA is. The average Duke undergraduate, for example, seems to have a GPA of about 3.45. You don't want to call attention to a 3.5 GPA at Duke, because this makes you look average.

In June of 2001, 91% of graduating Harvard students graduated with honors. Graduating cum laude sounds good, but at Harvard it might peg you as in the bottom ½ of your graduating class. Know what your GPA and honors status signal before putting them on your resume.

I'd Like to Know What You Want to Do

Yes, I know that basically you want a job :-) I once graduated from college, too, and my primary goal was a job. But I'm more likely to interview someone who indicates an interest in MY job. In the programming field there is a wide range of jobs to be done. I don't expect any candidate to be equally interested in: Give me some sense of what your interests are.

You might think that if you are applying for a job, then you are interested in it.

I'm not willing to assume that.

First, I have had people apply for jobs with resumes that looked good. Then, during the phone screen, it became clear that we did not do what they wanted to do (in this case, "we" build high tech inspection equipment and "they" wanted to design new network protocols. We don't do that). Second, I may be looking at resumes for multiple jobs. It helps if I have some idea which ones you care about. And finally, job postings are often vague (which is our fault, not yours). When in doubt you should apply, but it is still good to give some sense of what you are looking to do.

You May Need Multiple Resumes

There is a good chance that there are multiple types of jobs that you are willing to do. For example, you might be looking for either a machine learning job or a high-performance computing job. You will want to have a different resume for each. These resumes should be different mostly in the order that various skills and experiences are listed. Remember that you've got one page or less to get a hiring manager's attention, so the order of things you present on your resume should change based on the job you are trying to get.

Is this more work for you? Why, yes, yes it is! Next question.

Note that these two resumes should not contradict each other! If a random hiring manager sees both you want that to be okay. So, changing the order of things is fine. Changing the level of detail is fine. Claiming a different dream job on each is not fine.

Specialists, Generalists and Compartmentalization

When hearing that I want to see some focus, some students (and experienced programmers, too!) want to object that (a) they don't want to get pigeon-holed, and (b) they learn quickly and see themselves as generalists.

I have some good news and some bad news.

The good news is that many organizations (including mine!) do, in fact, WANT TO HIRE PEOPLE WHO CAN LEARN QUICKLY AND LIKE DOING NEW THINGS.

The bad news is that we want these people to be pretty good at the things they are learning quickly. We don't want "generalists." We want people who can come up to speed fairly quickly on something new and be good-if-not-great at it soon. The best way to SHOW us that you can do this is to have done it. Which means that you really want to be pretty good at something. Preferably two or more somethings. And preferably something computer programming related.

A specific example might lend some clarity:

If I'm trying to fill a position where writing assembly language is a key part of the job, I would much rather hire someone who knows one assembly language very well rather than hire someone who has bits of experience with a lot of different assembly languages. This is true even if the assembly language that a candidate knows is not the one I care about. The reason is that I expect that someone who is good at any one assembly language can pick up another one fairly quickly. I am not so confident that a dilettante who has played with lots of assembly languages without mastering any of them will actually be able to master one when the time comes.

A Little bit of Humor is Fine

I once came across a resume that mentioned the candidate's foreign language skills as:
Excellent spoken and written Spanish and German. Appalling French.
I looked at the resume a bit more carefully than average because I appreciated the humor.

A Portfolio is Nice

I like to look at examples of work you have done. If you have code that I can look at, you should make it available. You can do this on a personal web page. Candidates with a portfolio have an edge.

But ...

If you are going to provide code for me to look at, it needs to be good. I know you haven't been doing this for a living (or not for long) and I'll take that into account, but I shouldn't be able to read over your code and find bugs without even running it. I have, in fact, found bugs in code provided to me by a candidate. I found these bugs just by reading the code! This was bad. Make sure that the code you offer is the best you can do. If you really want to impress me, your sample code will also come with unit tests!

If you have worked on a project with a hardware component (like a robot or a car), pictures of the final product can't hurt.

Finally, I don't have a Facebook account. Your web page should be visible by people who are not on Facebook (or MySpace or ...). I'm not going to sign up for a new account just to see details not available on your resume.

Some Small Details

If You Have a Few Years Before Graduation ...

If you have a few years before graduation, you have a few years to do something to help stand out from the crowd. Write an iPhone app and publish it to Apple's App Store. Or do the same thing with Android. Or contribute to an open source project. Or write a Java applet to do something interesting and include this on your web page (along with the source code) ... and provide a link to this in your resume. Make a game that I can play with.

Finally

Good luck! Remember that hiring mangers want to find people to interview and hire. They don't like wading through lots of resumes and really hope that each candidate that they bring in to interview is one they can make a job offer to. Help them hire you by making your resume one where they want to talk to you!