If you’re writing a tech or dev resume, there are some big pitfalls I see on most resumes that cry out ‘don’t hire me’. Please don’t fall into these dead giveaways. It can be obvious in the first 5-10 minutes of talking to a candidate to determine if they really know what’s on their resume or are blowing smoke. Is it just naivety or an indication of honesty? The tips below are meant to help people write better resumes that lead to truly impressed recruiters and great jobs.
The general rule of thumb is: Don’t list something on your resume unless you really know it. Avoid Lingo Bingo. Seriously, just because someone has used a tool casually or occasionally coded against an API doesn’t necessarily mean they really know it. If a typical developer could learn it in a day, don’t list it. If you don’t feel comfortable demonstrating a depth of understanding on a topic, don’t list it.
Update (2013-04-03): The above still rings true if you’re handing someone your resume, but in todays age most recruiting is done with keyword searching, so lots of keywords can be useful. Also showing a breadth of exposure can be informative. I’d be more inclined to a resume that mentions MongoDB, ReSharper, and Ninject, even if it was light exposure, than a resume without. It is hard though with lots of keywords to understand what a candidate really knows to find a good place to go deep in understanding. So I’d revise the bold statement above slightly to say, only emphasis what you really know, and call out as keywords elsewhere additional techs you’ve had exposure to (as mentioned in “Still want buzz-words?” blow).
Warning Signs: The Buzz-Word List
- Frameworks: Be prepared to explain the key architectural components of frameworks listed (like WCF, ASP.NET MVC, MVVM, MEF, …) and why they’re important. For example, don’t list WCF if you’ve just used VS to connect to a web service as any joe dev could learn in a day. List WCF it if you know its ABC architecture and could write a chat service using WCF from a command line app, or do something else particularly interesting.
- Languages: If multiple languages are listed, like “Java” and “C#” be ready to be asked “what are fundamental language differences between the two languages?” (not just syntax, buy keywords and concepts). Like properties, interpretation of generics, multiple inheritance, partial classes, properties, delegates, etc. Same goes for VB.NET & C#. If you’ve used them in the same way, why list them separately?
- Versions: If you list separate .NET framework versions (like 1.0 to 4.0) then you should know differences between them, otherwise you’ve just used “.NET”. Same goes for languages, don’t list C# versions unless you can tell the differences between them, otherwise you just use C#.
- Specific Techs: If DHTML is listed, be expected to explain the difference between HTML and DHTML. If you list CSS, know pseudo elements, selectors, multiple classes, inheritance priority, etc. LINQ means you understand extension methods, expression trees, etc.
- Phrases: “Excellent Communicator”, “Project Planner”, “Organization Skills”, should have real, specific, damn good examples to back them up if listed. More often than not when I find these on a resume it shines a spotlight on an area that’s normally a challenge for the individual. Much better to list how those skills have been used in practice, like “Organized a team of 10 developers through the project planning phases of dozens of products over 5 years” or “written >30 product specifications, instructional documents, and FAQs”
- Once vs Frequent: Stuff done one time or here or there doesn’t count for much (unless it’s something totally awesome!). It’s better to focus on patterns and things done consistently.
- Methodologies: All software is done under some methodology, even it if doesn’t appear like it sometimes. No real need to list one unless it’s particularly unique or your into improving the methodology. Just meeting 15 min a day is not SCRUM. If I see “Agile” I’ll ask “so what does it really mean to develop software in an Agile way”. Many candidates can’t contrast Agile or SCRUM with other common development methodologies.
- Source Code Control: All developers these days are expected to use source code control of one type or another. It doesn’t really matter on a resume unless you consider yourself an expert in a SCC tool, so don’t be listing subversion or TFS (if you use it only for SCC).
- Bug Tracking: Same here, for the most part entering bugs or tracking issues is common and can be eliminated. It’s worth mentioning if you’ve actually worked on defining the bug tracking fields, put real though into it, analyzing data from the bug DB, and have skilz in that area.
- Super Basics: All developers are expected to have worked with basic technologies like SCC, DLLs, files, Windows (if in .NET), XML, etc. Don’t list them unless you rock in a way worth telling.
- Funny Terms: The way the buzz-words are listed is funny sometimes, like “C# .NET”. Wow, really, you’ve done C# in .NET? Or wait a minute… isn’t C# only done in .NET? (well technically .NET is Microsoft’s branding for C#, the BCL, and CLR, but hey, if someone told me that I’d be impressed)
Keys to Remember
- A Resume is a Quick Intro: The resume is just your entry into the door and springboard for discussion. You get hired on actual evaluation by the recruiter of your skills, experience, and communications. Let’s hope this includes some actual coding to.
- List Standouts: List things that make you stand out. Like writing Visual Studio plugins (if you’ve done it a number of times and really know what it takes), contributing to open source, a Stack Overflow rating to be proud of, etc.
- Less is More: If you list “just a lot of stuff” the gems will get lost in the noise. State just the things you really know and are particularly proud of.
- Still want buzz-words? If you still feel compelled to place lots of buzz-words on a resume for search engines or because that headhunter is pushing you to do so, add a “keywords” section to the bottom of the resume. Or another option is to list at the top “Competencies:” with what you really know and have a “Worked With: ” section for other buzz-words.
- Simple Explanation Test: “If you can’t explain something simply, you don’t understand it well enough.” – Albert Einstein, and it is so true, and “explaining something simply” means conveying why and how it’s important in a clear and concise way.
- Just be honest. Dead honest. It really does show.
p.s. For context… my last resume was one-page with relatively little text, mostly clean colorful use of whitespace, and only listed stuff I truly felt competent in. It landed me a job on the Microsoft Visual Studio Platform team. Now I’m reviewing dozens of resumes a month, and generally the more of these all-too-common pitfalls I see on a resume, the less competent the candidate tends to be.
Focus your resume to be a tool highlighting your best skills and spark a meaningful discussion with a future employer.
