Should resumés contain jargon? That is, vocabulary or terms that are specific to a narrow job area and understood only by persons familiar with that job area?
Yes, and No. It depends on your goal.
Yes, you should include (some) jargon if your resumé is targeted to the particular job area that employs that jargon. Technical (e.g., engineering), professional (e.g. legal or medical) and military job domains all have their own vocabulary, abbreviations and idioms. If your experience is in one of these domains, and you are submitting your resumé to be considered for a position in one of these domains, yes, you should include some jargon.
Note I say "some" jargon. I have seen resumés that go so overboard in this area that a) they become tedious and difficult to read, and b) the litany of abbreviations, acronyms, and specialized words leave a strong impression that the author was listing these words just to take up space. Every word in your resumé should provide value to the reader. Overuse of jargon can create the opposite impression.
I work in the computer software field. I write programs in several languages. I am skilled at software design and architecture. Most of my projects have been conducted producing software solutions on the Microsoft Windows operating environment, but some have involved the Unix environment as well as other less-familiar ones.
Here is an illustration of how I might include jargon to describe a project I have worked on.
* Led 6-member team in delivery of embedded, multi-threaded, RTOS/CAN-Bus implementation of automated, robotic-driven, fluid assay platform constrained by hard, 12-second cycle times from sample injection to result report. Followed Scrum approach with 2-week sprints. Component architecture implemented using GOF Design Patterns including: Abstract Factory, Decorator, State, and Strategy. Robust OO implementation in C++ rigoursly followed SRP, OCP, LSP, ISP, and DIP principles.
Now, if I am submitting my resumé to an organization that is doing RTOS and C++, this language and content may be perfect because the hiring manager in such an organization can reasonably be expected to be familiar with these terms and concepts.
However, if this illustration is all "Greek" to you, that is perfectly normal. If you have not worked in this area you would not be expected to understand all of this. But, and this is my real point, a lot of software managers who would receive my (or your) resumé also would not understand all of this because not everyone in software has worked in some of these niche topic areas either. Even an experienced software manager leading delivery of business applications would not necessarily be familiar with many, or any, of these terms or acronyms, and might decide I am being condescending or just trying to show off. I don't ever want to create that impression.
So, could I tone down the jargon? Sure I could. Here is the same description as the illustration above, but simply written for a reasonably intelligent reader - not for me the author:
* Served as Technical lead for 6-member team in delivery of a medical device that performed analysis of patient body fluid samples in an assessment cycle that could not exceed 12 seconds. Device was implemented in C++ in a real-time operating environment. I led the selection of appropriate design patterns and principles to assure desired quality and ease of maintenance.
Hopefully this is a bit more understandable even if you do not work in this narrow area of software. And just as importantly, it should be more understandable to a hiring manager who generally understands software delivery and just wants to get a clear, uncluttered idea of what I have done in the past.
And this is where I have to say that if your resumé is targeted to obtain a position different from those on your resumé, No, you should not include jargon. Or, at best, only a little, but include some explanatory descriptions. If I were to submit a resumé for a management position in, say, a financial area, the reader of my cover letter and resumé can be assumed to know little or nothing about low-level technical software concepts. So I would want to write a new "management" resumé for such a position, tailoring each set of responsibilities and accomplishments to show how I used or grew management skills in my previous jobs.
Here is the same illustration above, but now tailored to showcase the management skills I used:
* Served as Technical lead for 6-member team in delivery of a new medical device. Managed team staffing, and maintained budget tracking for executive sponsors. Provided first-level input on team member Pay for Performance assessments. Evaluated supply-chain vendors for device components and monitored their compliance to our agreed Service Level Agreements on defect correction. Assisted legal department in negotiating hardware contracts and costs.
Is this a different job that the RTOS/C++ illustation? No, actually it is not. It's just a different view on what I did on that project. Some of what I did with that team was highly technical. Some of what I did was purely project and product management. But in this third example there is no need for technical jargon: the content is for a potential management position.
I hope this clarifies that the answer to using jargon in your resumé really is Yes and No. And I hope it also strengthens your appreciation that having at least two versions of your resumé is a really prudent approach: one for continuing in your current job area if you find such openings; another version that is more immediately understandable to the reader if you pursue a new job area.
