If you're a programmer--especially a relatively new one--then chances are your resume sucks. There's no easy way to say that, but honestly, it's probably true. Is your resume five pages long? Do you have a quarter of the page loaded with every technology you've ever touched, read about, or brushed up against while walking briskly down a hallway? Pull up a chair then, and we'll try to fix your issues, omissions, and exaggerations. It'll make your life, and the lives of hiring managers much better in the process.
When I was consulting with AIG back in 2001, I was working at Series-I Support Services and the president of the company was consulting as the director of development up at AIG. The office building was about a two hour drive from our home office, so needless to say, I spent a lot of time in the car with him, and was privy to a lot of the hiring process. Later, when I was at Performance Technology Group, it was my turn to be in the director of development role, and it was my responsibility to review offshore consulting resumes. Finally, here at the University of Virginia (UVA) School of Medicine, as the lead programmer, I've been spending a decent amount of time helping out the Manager of Enterprise Architecture by reviewing resumes, participating in interviews, and helping to evaluate candidates.
I have some experience on the hiring end, but obviously I also have experience on the applicant end. When I started my job hunt that landed me at UVA, it had been 11 years since I last had to go on an actual interview. I was out of practice, and my resume also sucked. I received plenty of job offers, but it was my interview and knowledge that nailed it, not the resume. I've since corrected many of my own resume errors.
Objective or Summary?
Different resumes have different formats, and a lot of it is up to preference. Some lead with a summary or abstract, while others lead with an objective. I prefer to start my resume with a summary of a single paragraph that outlines my career as concisely as possible. This isn't the part of a resume that makes or breaks a potential interview, so don't ruminate over it too much.
If you decide to use an objective, make sure you tailor that objective to the job you are applying for, or at the very least the type of job. This isn't a part of the resume that should be generalized too much.
Most people use a cover letter in lieu of an objective. This lets you keep the resume about you, while tailoring the cover letter to the job posting for which you're applying.
Are Those Really your Skills?
The biggest mistake and greatest annoyance on any programmer resume is the skills section. Many programmers use this section to point out all of technologies they've ever touched. I've seen some half a page in length, and the running joke is that some applicants put things down as a skill if they saw the book cover for it while walking around Barnes and Noble. When I consulted with AIG, I was helping a fellow consultant with his resume and noticed Unix listed as a skill. I asked him about it (at the time, I was knee deep in Linux and Solaris), and he said that he never actually used it, but his company told him to put it down.
Want to know what else you shouldn't do? List every version of every single software you've ever used. There is no need for a line item that lists: Visual Studio 2005/2008/2010/2013/2015. If a company feels like you're experience is good enough that you can do the job, it doesn't matter if you're stuck on VS2005. I'm sure they'll be confident enough in you to believe you can pick up on a new version. Please just list the software, if you list anything at all.
Are tools even skills? There's a good argument for leaving tools off of the skills list unless usage of the tool is ubiquitous with the job (e.g., Photoshop).
What should your skills section look like? One line on your resume; two at the most. Your skills should be a group of items that nicely sums up those technologies with which you are especially adept. For example, my skills section looks like this:
Are those all the things I know? Absolutely not, but they are the items most pertinent to the job experience I have listed on my resume. Just because I have programmed a few things in Clojure doesn't mean I'm going to put it as a skill on my resume. I would mention those items in my cover letter, and include them in my portfolio.
A Resume is not a Portfolio
Speaking of portfolios, the biggest mistake any programmer can make is loading everything he or she has ever done onto his or her resume. Your resume is not your portfolio. We live in an era of LinkedIn and GitHub. Use LinkedIn to list everything under the sun, and hiring managers can review that if they feel the need to. I've been programming since 1998. My resume is two pages long, and that includes awards, speaking engagements, and relevant college research work. There is no reason that a junior developer with 5-6 years of experience should have a five page resume.
Most junior programmers have large resumes because they feel the need to show all of the work that they've done in order to get an interview, or impress the hiring manager, but most hiring managers hate navigating through verbose and archaic technological jargon in order to decipher what was actually accomplished. You should be as concise as possible, while actually explaining what you did. Give the interviewer or hiring manager a reason to ask you to elaborate. I usually give a brief paragraph detailing the primary task(s) of a job and the technologies used to accomplish the job. I then give a few bullet points of major milestones.
If you have beyond ten years of programming experience, only put the last ten on your resume. I was previously guilty of listing all of my experience, but honestly, nobody cares what I was a webmaster or systems administrator of almost 20 years ago.
There are certifications and then there are online learning mills. If you have a certification from Microsoft or Oracle (or other such company) that requires you to sit for a proctored exam, you should list that on your resume. If you have course completion certifications from PluralSight or Lynda, leave that off.
Also make sure your certifications are relevant to the job you're seeking. I don't list my Java certifications on my resume because I'm not looking to go back to Java, so it's more important to me to have extra real estate on my resume for other things.
Beyond Job Experience
Programming resumes can often run into two pitfalls: too little information and too much information. Both of these usually stem from a lack of experience, while too much information can be a sign of insecurity.
If you don't have enough work experience to fill in a resume, you should think about moving your education section above your experience. You should also consider including a section for projects that includes applications built while in school. If the resume still looks light, expand your education section to list classes that might be relevant to the job you are seeking. If you're a computer science graduate, adding the programming courses you took might help (or specific courses such as mobile development or functional programming, depending on the job).
If you've trimmed your skills listing and your work experience, but your resume is still too long, you might be loading it with education, side projects, and other material that you really don't need. Leave this stuff off unless it's really pertinent to the job. If you're applying for a job that builds business software in Python, but you did research work building handheld terminals with C++, you probably shouldn't waste resume space by listing it. Save it for the interview process. If you're afraid that you might not get the interview if you don't have that listed, bear in mind that although the project might pique some people's interest, it'll likely have no influence on shuffling the candidate pool.
My resume has three specific components that are in addition to the traditional resume sections: awards, speaking engagements and presentations, and projects. The award was a proud moment where a mobile application that I built received a second place prize from an emerging technologies conference. Though if I needed the space, it might be the first to go because I'm not currently focused on mobile. It's partially there because winning awards is something to be proud of, but also because the award was for a project built for Peirce College--a higher education institution that I consulted with--and my current job focus is in higher education.
Projects, meanwhile, is another section that would probably go if I was seeking a job outside of higher education. It relays my undergraduate and graduate research work dealing specifically with learning management systems and educational tools.
The section for speaking engagements and presentations exists as a way to show that I am making an effort to be an expert in my field, and attempting to share that information with others in the field. If you've had the opportunity to speak, it's always a good idea to include that--space permitting.
It's important to note that all three of these sections could easily be left off my resume. They are additional information areas that could easily be swapped out if I decided on a new career direction. They could also be dropped in favor of other information. The takeaway is that even with them on my resume, it still clocks in at two pages. These additional sections aren't going to be what nails down an interview. That will depend on how I've conveyed my accomplishments at each job.
On my resume, under my name and contact information, I have two links: the aforementioned LinkedIn and GitHub. If a hiring manager cares to learn more about my career, my LinkedIn profile should provide them with the more detailed view.
GitHub, meanwhile, has become a tool that hiring managers use for code review. Prior to accepting at UVA, my job search revealed that almost every interviewer was curious if I had a GitHub account. More and more GitHub is being used not just as a source control repository, but as a portfolio. It doesn't hurt to keep some code in there that you're proud of, so that you can point to it when asked.