Most tech resumes suck. As someone who’s worked in tech for years, and spent time on two startups in the human capital space (ProjectSherpa and Scouted) focused on analyzing resumes, including the tech resume, I can say I’ve seen tens of thousands of resumes, and they are, on average, bad. If you’ve ever done any amount of technical hiring, you’ve undoubtedly seen the archetypes: 10-page resumes, gigantic lists of acronyms and skillz, and unintelligible project summaries. What follows are some tips and suggestions for how to revise and optimize your tech resume.
Some genius and diabolical recruiter must have created the original tech resume template which has now become so commonplace.
The tech resume simultaneously caters to recruiters while impeding hiring managers. The abundance of keywords and key phrases plays up to the recruiter mindset: ignore the person, find the right alphabet soup. Similarly, the obfuscated set of work history descriptions prevents hiring managers from gaining too much relevant insight about candidates. Most hiring managers have neither the time nor the patience to read through a technical novella, let alone the hundreds seen during a typical hiring cycle.
Tech Resume Skills
One of the most obnoxious and often-seen sections of a tech resume is usually labeled under “Technical Skills” – for example:
Languages: C#, Java, SQL, Python, Shell Script, DOS Script, JavaScript, HTML, SML, etc.
Technologies: Tibco, Spring, Servlets, JSP, Struts, XML, .Net Framework
Databases: MS SQL Server, Sybase, Oracle, DB2, MySql
Database Tools: Oracle SQL Developer, Rapid SQL, Toad, Microsoft SQL Server 2005
Development Tools: git, Eclipse, JBuilder, Visual Studio 2005/2008, ANT, CVS, SVN
Platforms: Windows 98/2000/XP/Vista/7, Linux/Unix, Sun Solaris
There’s so much wrong here!
- If you list a technical skill, be prepared to answer questions about it. Are you really experienced and proficient in all of those technologies et al? You really got mad skillz in all that stuff, yo?
- What does listing every flavor of Windows accomplish? Do you even want to work for a place still on Windows 98?
- Are you applying for an application development position? If so, it is overkill to list each database tool you’ve ever used.
- Do the categories make sense? Are items categorized appropriately?
- Are you equally proficient in all of these ‘technical skills’? Are you listing some things out of emotional attachment from that one time 8 years ago when you wrote that small utility app?
Don’t do this in your tech resume!
It’s highly unlikely you are in fact an efficient developer in all of these programming languages, proficient with db development across all of these stacks, and comfortable developing on all of these platforms and with all of these tools. All you’ve done with this Skills section is given recruiters (and automated resume parsers) a few extra reasons to spam you, and opened yourself up for questions you probably can’t answer.
One excellent alternative to the Skills section is to note the technologies used within the work history descriptions – hell, you might be doing that already! For example:
Firm In My Past
2006 – 2007
• Design and development of a C#-based Excel plug-in that hooks into the firm’s trading application suite.
Though this is a trivial example, simply moving the technical skill to where it’s relevant accomplishes so much. You are providing context which can imply level of competency (a C# Excel plug-in is a much different level of complexity than a C# trading application suite); showing how long ago you used the technology, which can account for why you don’t remember all the syntax and errata; and filtering out some of the noise which gives hiring managers headaches.
Consistency
Consistency is especially important on tech resumes because…
Attention to Detail
Even if you don’t know coding, you can tell that the above snippet is ugly. There are misspellings, variable names are not informative, there’s no consistency around use of braces, underscores or indentations, the sole comment provides no insight, error logging is not helpful. This snippet shows no attention to detail, lack of experience, and/or lack of care – all things you wouldn’t want to demonstrate on the job, or if you care at all about your work.
If your tech resume is riddled with misspellings, bad grammar, weird capitalizations, and lack of formatting, then who’s to say your on-the-job work, emails or programming or other, will look any better.
Grammar Rules for Tech Resumes (and Others)
There’s no shortage of helpful sites on resume grammar – pick a few and follow the rules. Some of our own suggestions follow.
Stick to one verb tense. If your job description bullets mix between present and past tenses, you’re doing it wrong. Just stick with one tense.
Bad
- Designed write-ups for migrating…
Implementinga new XML feed…
Good
- Designed write-ups for migrating…
- Implemented a new XML feed…
Do not end some bullets with a period, and others with nothing. If you want to finish each bullet with a period, do that, but be consistent.
Do not arbitrarily capitalize. Capitalize proper nouns and the first word of sentences (generally). This is a Very Bad example: I created stored Procedures, Tables, and Views for each Product. Also note that many resume purists suggest avoiding ‘I’ or any first-person references.
If you capitalize an acronym, make sure you capitalize it similarly throughout. For example, do not write ‘xml’ in one place and ‘XML’ in another.
For marks like ampersands, slashes, and dashes, decide when and why you want to use them, and stick to those rules.
Are your bullets all lined up and indented to the same place? Do you apply consistent date formatting? Are your job titles and positions formatted similarly across your work history? If your resume has section headings, are they formatted similarly? Have you even read the damn thing yourself!?
A perfectly formatted resume that’s light on content is like lipstick on a pig. Bad formatting and improper grammar distract the reader, so it’s important to clean these up; however, a resume needs to convey some sense of YOU. Why are you interesting? Will you be a good fit for this firm? Can you do this job?
Who is the Audience for your Tech Resume?
The first question to ask is: who is your audience? Who is reading your resume? A recruiter is looking for very different things than a technical hiring manager. It can make sense to have multiple versions of your resume, serving content based on the expected reader. Recruiters, generally speaking, are most interested in keyword matching. The closer the reader is to the role, the more familiar he or she is with the specifics. Find out who will be reading your resume and tailor it for maximum impact.
If you’re working with a recruiter, ask if you can send over a new version before sending the resume off for first round reviews. It’s not critical that you customize your resume for each different reader, but at least consider whether what you’ve written is relevant for your audience.
Tech Resume Tidbits
Be concise.
If you’ve been in the industry for a long time, you may have a multi-page resume. (Although if you have less than 5 years of work experience and have a multi-page resume already, you’re doing it wrong!) If you get bored reading your own resume it’s safe to assume everyone else will as well.
Be specific.
“development of client-server web-based applications”
What is the technical hiring manager looking for? This is a tough question to answer generally, of course; however, it’s safe to say that most hiring managers will be curious to know about your recent projects, and what impact you made on those specific projects. To that end, give some specifics! Describe the project you worked on, either in paragraph form or throughout the bullets. What did these applications do?
Demonstrate that you can understand and solve problems.
Many technical folks view programming as a tool for solving problems, and the best developers transcend a specific toolset, learning what’s needed and using what’s most appropriate for solving those problems. Demonstrate that you’ve learned whatever business in which you were working, and can solve problems in that domain.
Convey with purpose.
“managed deliverables for all projects”
For each of your bullets, ask yourself, what am I trying to convey? What exactly were the deliverables? What was the scope of your management with regards to these deliverables? A generic statement doesn’t just tell us nothing about your work experience, but it also shows you’re not a good communicator.
Don’t be afraid to delete from your tech resume.
“guaranteed accuracy of project deliverables based on estimates”
If a bullet conveys nothing, and there’s no room for improving it, remove the bullet entirely. Saying you “worked on projects to meet goals” is completely pointless! Of course you worked on projects, and of course you worked towards goals! Get rid of your resume bloat.
Showcase metrics where available.
“improved system architecture to improve general system performance”
If you have an opportunity to give meaningful metrics, jump on it if they add credibility. Did you reduce the memory footprint from 8GB to 2GB, or did you just remove some unnecessary instance variables? An interested interviewer who digs into this bullet will ask for the specifics, so you might as well give some of that upfront.
Don’t be afraid to show off your uniqueness.
“designed and taught an internal course…”
Highlight interesting achievements, even if they did not occupy a majority of your time. These achievements separate you from the crowd, they make interesting talking points, and they give you an opportunity to show yourself off during the interview.
