As a contractor, your curriculum vitae is your most important sales tool. It should define who you are, your experience, qualifications and background, and should do so as informatively, clearly and concisely as possible.
You’re not trying to write a best–seller here, but you are trying to make a good first impression, capture people’s attention, and make sure your details stand out from a pile of others.
While curriculum vitae might be Latin for “course of life”, prospective employers don’t want to know everything. Three years in an Indian ashram having out of body experiences is probably not relevant for the post of telecommunications engineer. (Then again, perhaps it is.)
So Rule One for CV writing is: a CV is a summary not an autobiography. What’s the first thing a CV reader looks at? Certainly not your name, address or hobbies. In all probability they’ll have a stack of CVs in front of them and they want to be able to quickly scan through each to see if the prospective candidate meets their requirements. Are they a probable, a possible or a no-hoper?
The most sure-fire way to get in that latter pile is to use what I call the “slab-o’-text” method. There are two ways to approach this. You can either bury everything in a single monolithic paragraph and ramble on like Proust, or you can break your experience up into your various jobs, then give a two- or three-page dissertation on each. Either way will ensure your tome finds a comfortable resting place at the bottom of the bin.
People are busy. They don’t want to spend half-an-hour teasing out the details of your life from a multi-volume document, so Rule Two of CV writing is to use bullet points and be concise.
While you’re at it you might like to expunge or explain all those technical terms in your CV. Stuff like “responsible for the reinterpretation of the Lempel-Ziv-Welch algorithm by using bit-wise operators” might be deep and meaningful to fellow tech-heads, but it’s far better to simply say you worked on improving data compression.
Remember, your CV won’t necessarily go to technical people. It’ll go to agents and managers and project leaders — people less concerned with the nitty gritty than with your responsibilities and results.
Rule Three: Annihilate obfuscation by implementing a rigorous decomplexification schema. Keep it simple, stupid. In a similar vein, the IT industry is littered with meaningless titles. It’s not surprising because a “highfalutin” title is a lot cheaper than a pay rise.
“Systems engineer” sounds much more imposing than “programmer” in the same way that “waste disposal facilitation technician” sounds better than “dustman”. But such fancy titles can get in your way when people are looking for a code cutter — or someone to clear out the rubbish.
Rule Four: if you must use fancy titles, at least explain them. As you may have discovered, IT managers (or rather, from a contractor’s perspective, prospective employers) are different from other people; they look for different things. In particular, they want to know what you’ve done and what your results were, so give them that information as clearly and concisely as possible.
Here are a couple of examples:
- In January of 1997 I moved to Bloggs Data Systems to work on the development of their DUMBASS project. Though it involved a lot of work and many late nights the project was successfully completed in June 1998.
- January 1997 — Bloggs Data Systems, C++ programmer. Part of a team to develop a new financial reporting system. The system was implemented on time and under budget in June 1998.
Apart from being an example of concision (Rule Two), look at the amount of extra information the second description imparts — and in fewer words too. Compare it with the first example. What was DUMBASS? Does the reader really need to know this acronym?
What was the applicant’s role? Analyst? Project manager? System tester? Tea-maker? So the project was completed, but was it ever used? “Completion” in this business is often a euphemism for a total cock-up that’s eventually abandoned.
Now look at the last line of the second example. Not only was the system implemented but it was done so within the project’s parameters. In other words, it was a success. And let me tell you, managers just love the words “on time and under budget”. They’re dulcet tones to their jaded ears. But don’t overuse them. We all know that such things are about as common as snowballs in summer in this business.
Rule Five: Be “work done” and “results achieved” oriented.
Just like Monty Python, there is NO Rule Six so we’ll move right along and look at the ideal CV format. It’s up to you whether you use a fancy title page, but the first real page of your CV should contain a concise summary of who you are, how to contact you and your areas of expertise.
- Company Name: (If applicable)
- Email Address:
- Date of Birth:
- Citizenship: (If you’re seeking work overseas or foreign to New Zealand.)
- Availability: (eg. “End of April”, “Immediately”, etc.)
- Educational Qualifications
- Technical Skills Summary
Item 1, years' experience
- Operating Systems
Item 1, years' experience
- Programming Languages
Item 1, years’ experience
Item 1, years’ experience
- IT Experience (by business)
- IT Experience (by role)
The last two headings are of course only relevant to those with multi-role or multi-business experience (as you will have after a few years contracting). Here, for example, you might indicate you’ve spent five years in local government, two in retail banking and three in insurance. And of those you spent six years as an analyst/programmer and four as a team leader. (Remember Rule Four?)
The whole function of this first page is to act as a useful piece of shorthand for anyone looking at your CV. From it they can tell at a glance whether you have the technical and business background they’re looking for and, if so, can turn the page and find out more.
Most of the remainder of your CV should be made up of your employment history in something like the following format, repeated for each employer you’ve had. (Keep it relevant. IT employers aren’t going to be bothered whether you picked oranges during your OE.) And jobs should be listed in descending order, that is, with the most recent first.
- Company 1: (Most recent first)
- Skills Summary:
- Duties and Achievements
- Company 2:
Notice the clarity of the layout and how easy it is for a reader to quickly skim through and build up a picture of the sort of work you’ve done. The duties and achievements section is particularly important as it allows you to be more specific about your role. Few programmers, for example, do nothing but program. There are almost always other aspects to the job that aren’t explained by the job’s title.
Note too the lack of jargon and technical terms as well as a lot of the gory technical details. If people want to quiz you about that mainframe-to-PC interface they’ll have to get you in and interview you, (where you can really sell yourself). After all, you’re providing a summary, not a tutorial.
The last section of your CV is optional but highly recommended:
- Hobbies, Sports and Outside Interests
- Hobby 2, etc.
- References (include at least two)
- Contact Details:
At an interview hobbies can provide conversation points outside the purely technical arena (“Ah, so you’re into nude bungy jumping as well!”) and provide a useful reassurance that you have a life outside of your work, which in turn indicates you’re a well-rounded individual.
Sometimes hobbies can provide useful crossovers as well. Membership of a local toastmasters group might indicate you’re comfortable with making presentations, for example. Or organising charity events indicates you have people management skills.
Don’t go into too much detail though. Just a sentence or two. And be a little circumspect about listing too many computer related hobbies. Contributing to the Open Source project may indicate you’re a Unix buff, but an employer might be entitled to wonder whether your mind is going to be entirely focused on the system he wants you to write for his Windows PCs. If you’re into hacking, cracking and distributing warez … I wouldn’t mention it.
If you don’t supply references you’ll probably be asked for them anyway, so it’s a good idea to get these sorted out at the start. A referee should be someone you’ve worked for professionally, who can verify your integrity and the quality of your work. Make sure you ask them before including them in your CV and don’t be tempted to use friends or relations — or if you do, ensure you make your relationship to them clear.
Ideally your referees should include your last two employers. This is especially the case if you’ve been contracting for a while as you might have lots of three- and six-month blocks of work in your CV that could otherwise be misinterpreted. (Note that in the Position column of your Employment History it’s a good idea to indicate whether your roles have been permanent or contract.
The role of a referee is not an onerous one. They’re there to confirm what you’ve claimed in your CV is correct and a typical reference check only takes a couple of minutes.
There are no hard and fast rules and a lot of it depends on that Employment History section, but as a guide a good CV should contain between three and six pages. If you find it’s much longer than that then it could probably do with some editing. If it fits on half a page then you either need to add a little more detail or seriously consider whether you’ve got enough experience to put yourself on the contract market right now.
I realise I’ve been making the assumption that you’ll be using a word processor to prepare your CV. That’s the best method, but there may be times when you don’t have access to a computer. Never, never, never submit a handwritten CV. You’re trying to project a professional image and nothing will demolish that quicker than half a dozen pages covered in your semi-literate scrawl.
And while we’re on the subject of presentation, always print fresh copies. A stained, badly photocopied, dog-eared CV is unlikely to get a second glance. If you’re presenting your CV to clients (see Going Direct in the next section), slip it into a smart folder with your business card. If you’re posting it, add a covering letter and use an A4-size envelope. Don’t scrunch up all your hard work and jam it into a regular one.
If an agency asks for your CV, give them a paper copy and one on floppy disk. Microsoft Word is the usual format but I always save a duplicate in the de facto standard Rich Text Format (.rtf) just in case. That way if they do use something else, or have an older version of Word and no converter, they can still get at your details right away. (Check: having saved a copy in RTF, ensure it’s still readable. Not all fancy formatting will be saved in this format).
Remember, your CV is a living document. Keep it up to date and keep working at ways to make it better.
CV Killers: 10 Ways to Make Sure Your CV Goes Straight in the Bin
- Not providing enough detail about relevant work experience.
- Providing information in a way that is difficult to read.
- Using too much technical jargon or long-winded explanations.
- Boring the reader with lots of irrelevant detail.
- Using slang, colloquialisms or lots of arcane acronyms, you know, eh?
- Burying all your details in a single slab of text.¥ Not using bullet points or a clear, easy to follow layout.
- Spel things rong and and make grammatical mistakes.
- Do it in your own handwriting
- Distribute grubby, dog-eared, badly copied photocopies that look like they’ve done the rounds of every employer in town.
Wrap up: CV writing rules
- A CV is a summary, not an autobiography. Include only relevant detail.
- Be concise. (Use bullet points if you like.)
- Write for a general audience, not a technical one.
- Explain your roles. Titles are often meaningless.
- Describe what you’ve done and the results you achieved in each of your IT positions.
If you want to read more about the New Zealand IT Contractors Handbook 2000, click here...