I usually read 5 - 20 resumes each week. Both my boss and I are extremely busy, so it's important that a programmer's resume grab our attention quickly by providing the right mix of necessary information with something that makes that person stand out from the pack.
I've been involved with our hiring process for more than six months, so I feel fairly confident that I can distill what it takes for a programming resume to get me to say, "Let's arrange an interview." Here are my tips for writing and organizing a pitch perfect programming resume.
Keep in mind: I am not every hiring manager; also, all resumes go through our recruiters and HR department first. Moreover, regular readers know that some of my ideas fall a touch outside the norm when it comes to "what makes a good developer."
Put your skills front and center
Reading the in-depth details of how you used mainstream skill XYZ to accomplish typical task ABC is not at the top of my agenda. I want to see your skills up front, so I don't need to go trolling through your resume to see if you meet my minimum needs.
Skip the summary and maybe even the objective
Those summaries are a waste of my time. It is going to say something like "seasoned IT pro with great communication skills" or "proven veteran with 10 years of programming experience." How do I know this? Because they all say this. Skip it, please.
The objective is a slightly different story; it is useful only if it informs the interviewer about something that the skills and experience does not. The objective's relevance to me is largely a function of whether you wish to keep doing what you have been doing. If I see you have been programming -- particularly at the data access layer and the business object layer -- and there is no objective, I am going to assume that you are looking for more of the same with a different employer or location. If you want to do more of that work and put an objective, you are wasting space. If you are looking for a change of pace -- like getting more into the presentation layer or heading towards a management track -- it's important to state that in your resume. Otherwise, we may discover during the interview that you are not interested in what we have to offer.
List your education last
Some IT hiring managers put a huge emphasis on certain educations but I do not. I always want you to list your school and your major, but I will only ask you about your education if there is something unusual or intriguing.
For instance, a candidate with a Computer Science degree from MIT or with a PhD in Organic Chemistry will draw my eye because these degrees show a level of high intelligence. On the flipside, an AA in basket weaving or a lack of a degree will not count against you.
In most cases, I am not even curious about your education until I have already made up my mind. This includes certifications -- MCSEs and CCNAs do not impress me that much at this point. They matter to some folks, and they do not hurt you in my opinion, but I will only take that certification into account if all else is equal.
Show me that you are different
Even if my project is a run-of-the-mill Web-based, data driven application (which it is not), I still want to see that you are more than someone with 10 years of experience writing run-of-the-mill Web-based, data driven applications. For example, compare these two items:
East Coast Power - Programmer 1999 - 2005
- Wrote VB applications to control machinery. The hardware interface was handled in a COM library that was written by another team. Application was robust and reliable.
- Wrote Web-based tool to track system faults.
- Created Web service to allow partners to consume portions of the database.
East Coast Power - Programmer 1999 - 2005
- Wrote VB applications to control nuclear reactor. Real-time control and monitoring of systems handling 10,000 unique data inputs per second.
- Wrote advanced algorithms in C# to detect imminent system failure, which were used within a Web-based application.
- Created Web service in C# to allow partners to access data in a secure, reliable, and responsive manner; typical data set was 1,000,000 rows and concurrency challenges needed to be overcome at the database and application layers.
See the difference? Control machinery does not help me much -- you could have been working on the elevator system for all I know. Programming a nuclear reactor impresses me, especially since there has not been any nuclear reactor disasters during your employment. Writing advanced algorithms in C# touches my engineer's heart; whereas writing a mere Web-based tool is ho hum. And, while writing a Web service is fairly simple, particularly in ASP.Net, it's not so easy to write one that is "secure, reliable, and responsive" with that size of a data set. It's also not easy to deal with concurrency issues at two different levels.
I am not saying that it needs to be wordy or full of minute details, but if you are doing work beyond what a summer intern could do, I need to know about it. Every developer has written a Web-based, data driven application. Show me more.
Make sure that your experience highlights your skills
I don't expect your employment history to include a list of all your skills. But if you are looking for work as a .Net developer, show me that you have done some .Net work. If you do not list that experience, I am going to assume that you have little or no experience with it -- even if it is on your skill list. If you have large amounts of experience outside of the workforce, find a way to show that on your resume.
Keep your resume between two to four pages long
I have struggled through seven-page resumes filled with jargon and boring details that made me want to cry. An overly long resume doesn't necessarily make me rule out a candidate, but why make it hard on me?
On the other hand, a resume that tries to stick to the one page rule is not going to cut it for a technical person unless they are new to the field. In my experience, two to four pages is just right. Also, please use some whitespace, so I do not feel like I am drowning.
Watch your formatting
While technical pros' resumes do not need to be pretty, formatting can make a huge difference in a resume's readability. If you cannot put three pages of text in front of me in a readable form, do I really want you touching the UI or writing code that someone else might have to maintain?
I recommend that you stick to a larger font size (e.g., 10 - 12 pt.) in a font that reads well onscreen and in print (e.g., Verdana, Arial, Tahoma, Calibri, Helvetica). If you want a slightly fancier font, use it only for section headers. Also, do not mix Serif and Sans Serif fonts -- that is just ugly. Do not use "Comic Sans" anywhere, especially in hot pink or baby blue (and yes, unfortunately, this needs to be stated). Keep your margins and space between paragraphs large enough to provide the reader some "breathing room."
I give applicants some slack on employment history. For instance, five year stints are fairly rare in IT, and I give anyone a lot of leeway if their history includes anything that occurred during the dot com boom/bust.
If you are (or were) a contractor or consultant, make sure that is clearly stated; otherwise, I will think that you get fired and/or quit every 3 - 12 months. If you were not a contractor or a consultant, and it looks like you have a hard time staying at a job, I am going to be very cautious. If I see an increasing progression of job titles, "mercenary" pops into my head. Also, if I see that they are lateral (or worse, negative) moves, "bad apple" is my first thought. Of course, sometimes you get hit with a string of employers that go under or get acquired -- it happens to the best of us. If that is the case, find a way to convey that information so I don't think you are unemployable.
Spelling and grammar
It is critical that the spelling and grammar in your resume is flawless. I have seen applicants misspell the name of their state and the name of their school. If grammar and spelling are not your forte, ask someone to look over your resume for you. While I understand that many IT pros are not native English language speakers (or are English language speakers who paid little attention to those subjects in school), you should still ask someone for help. In fact, knowing when to ask for help is a hallmark of the best developers. If I interview you and realize from your speech that you had the sense and humility to ask someone for help on your resume, I am going to be truly impressed. (For examples of what not to do, check out this list of real-life resume blunders.)
Stay out of EEO (Equal Employment Opportunity) territory
In the United States, companies with more than 10 employees need to follow EEO rules. These rules state that an employer cannot discriminate against or show preference for an employee based on certain group membership items or personal lifestyle issues, such as gender, age, ethnicity, nation of origin, religion, sexual orientation, and so on. So, do me a favor and try to not expose any EEO-related information to me on the resume. In a face-to-face interview or even a phone interview, some of it will be unavoidable. But I will never solicit that information. Not only do I want to keep my employer and myself out of trouble, but I personally feel that EEO is important. I can understand that many names (or even college attended) are strongly correlated with ethnicity, religion, or nation (or at least general geographic region) of origin, and college graduation or attendance dates give some age clues. Minimize this as much as possible. Please do not tell me about your church, your family situation, your home life, your parents, and so on. It is not that I am not interested -- I would probably love to learn these things about you if we hire you -- but I do not need or want to know them before that you come on board.
Outside interests, hobbies, achievements, and activities
I like to see these, but only if they are relevant. I really do not need to know about how big of a fan you are of the New York Knicks; but if you wrote a piece of software that can do something nifty with the team's statistics for fun, I would love to know about it. People who contribute to open source projects get a huge gold star in my book, but only if I feel like they would be comfortable working on proprietary software with proprietary tools, and not bringing anything GPL'ed into my codebase. That is a small caveat there. "Contributed to project XYZ in the areas of ABC and DEF" is enough to whet my appetite. Show me some outside learning too -- don't let me think that you get home at 6;00 and shut off your brain. If this work is not interesting enough for you to read about or experiment with on your own time, why would I think that you will be engaged or even interested in the job we would hire you for?
Gracefully show your inner geek
Please give me something meaty that we can discuss during the interview. So, where it is relevant, try to show me how much of a nerd you are.
For instance, try to mention the hovercraft you made from an inner tube and a lawn mower engine. Make note of the iterative, evolutionary game theory system you coded in Lisp that proves that Nash's equilibrium is dead wrong. Tell me something about your three chess championship victories. I do not want to know that you memorized UHF or that you have a pocket protectors collection that have logos of now defunct minicomputer vendors.
I know most of this falls under the previous section, but it is relevant. I love to work with programmers who love technology and logic and using their brains. People like that are simply better programmers. Why would I want to hire someone who is intellectually lazy for an intellectually challenging job?
Obscure or nonmainstream technologies
I am not hiring Lisp, Prolog, Erlang, APL, Scheme, Clipper, PowerBuilder, Delphi, Pascal, Perl, Ruby, Python (forgive me for including those four in this list), Fortran, Ada, Algol, PL/1, OCaml, F#, Spec#, Smalltalk, Logo, StarLogo, Haskell, ML, D, Cobra, B, or even COBOL (which is fairly mainstream) developers. If you show these on your resume, I will want to interview you just for the sake of slipping in a few questions about these items. I am serious. As part of my secret geekiness, I am really into obscure and almost obscure languages and technologies. I know that a lot of those items take better-than-industry-average intellect and experience to do; they also provide a set of experiences that gives their practitioners a great angle on problems. While you will never directly use those skills in my shop, you will be using those ways of thinking, and it will give us something to talk about on your first day.
(Aside: A coworker was shocked to learn that I played Half Life. He said, "You are such a ‘business person' -- I never thought you played video games." I guess I'm camouflaging my secret geekiness too well!)
I've given away crown jewels here. In my perspective, these tips will help any programmer write a perfect resume and get them an interview.
What do you think gets applicants an interview? If you read resumes as either a hiring manager, a recruiter, or an HR employee, what makes you say "wow!" or "ugh!" when you see it on paper?
Justin James is the Lead Architect for Conigent.