While there is scant sign of the current general economic malaise breaking, Developers, and Web Developers in particular are enjoying strong demand for their skills. So with good opportunities available for talented developers it's worth making the effort to differentiate yourself and take advantage of the favourable job market. Perhaps the most important tool at your disposal, is your CV.
It's good to think of your CV as like a tool, no different from a programming language or an IDE. Like any tool it has to be rigorously tried, tested and possible refactored if it is to be successful and help you achieve your goals. In the case of a CV its purpose is two-fold, a) to get yourself past a recruiter and onto the actual client and b) to impress the client sufficiently that they want to interview you. So in the spirit of the new year and everyone having 'ten things' lists, here's mine for what to avoid in a modern CV for an IT role:
- Don't send an old CV. If you haven't updated your CV in months, let alone years, it isn't going to sell you as effectively as it can. As a developer or even a recent graduate you're learning all the time. Detail and demonstrate as much of that learning (that is pertinent to the job at hand) as possible. As you get older, more experienced, your perception of what is and isn't important improves. While recently reviewing my own CV I found I had added a significant amount of detail, while actually reducing the overall bulk of the document.
- Please, do not include an interests section. This point is somewhat subjective I grant. But of the CVs we've been forwarded all but one had an interests section. Not one of these contained anything relevant to the job being applied for, and in some cases actually contributed to us ruling the candidate out. When hiring, a client is seeking a professional. Telling them you spend a lot of time playing 'World of Warcraft' in your spare time isn't going to get them jumping out of their skin to interview you - particularly if you don't qualify how that interest is relevant to you performing the duties required.
- Avoid sending a generic CV. Applying for jobs is tedious, time consuming and not immediately rewarding. But sending a generic CV detailing every subject you did at GCSE and A levels doesn't tell the client why they should hire you, and you specifically, for the job at hand. Oh and most clients seeking developers don't care if you worked at Subway or have a Tesco certification in fish mongering, it's simply not relevant.
- Web 2.0 extravagance might be 'in' right now, but try to keep your CV conservative, well spaced and using a minimum of fonts. Giant mastheads, fancy bullets, a giant mess of fonts, it isn't impressing anyone, seriously, and most recruiters gut your CV into a standardised format anyway. Do be mindful of how it is to read. Clean and clear is the key, but save the extra special effort for the content.
- Don't go on for longer than two pages. Trying to cheat this rule by making the font so small that a microfiche reader is required is only going to annoy the recruiter. That means your CV gets forwarded to the 'round file' not the client's inbox.
- Don't list every course you did at University and expect the client to care. Of our graduate applicants not one has detailed what the courses actually contained. Database Systems 1. Cool - and you did what exactly in that course that is relevant to the job? It's often difficult for graduates to pad out their CV in the same way as someone with a few years' experience. Treat your degree like a job, work out what specific skills you got from your courses and detail the skill qualified with a practical example of how you applied it in your course work. Start doing that for all of your courses and very quickly you'll bang into the two page rule. Keep going, but when you're finished pare down the text into bullet points that are directly relevant to the job spec.
- Spelling mistakes! Simply do not forget to proof read your CV. This really ought to go without saying. Get your sister, mother, girlfriend, house mate, anyone, to read your CV before sending it. Read it backwards, turn the zoom up to 400% and read it one word at a time. Anything to ensure that what you send out is as professional as you are. A sloppy CV leads to a sloppy impression. 'The Halo Effect', while not always fair, is something you have to deal within the real world. If a client's first impression of you is a bad one, all subsequent impressions will be shaded by it.
- Don't include a picture of yourself. Like ever. It's simply not necessary.
- Don't ramble, don't generalise, don't make statements without qualification. Good use of English is one of the best indicators of a good developer. Good code is succinct, clear and well qualified (unit tested). Like PHP, Java, indeed any programming language, English has a grammar, a vocabulary and patterns of use. Make best use of these attributes in your CV. Constantly refactor your CV to weed out redundancies, group like concepts, simplify and support the concepts. Like good code, a good CV goes through many iterations until it's 'good enough' for the real world. Mercilessly refactor your CV as you would your program code.
- Don't accept everything you read on the net about CVs as gospel. This caveat applies to everything in life and not least this blog itself. If you listen to every top ten list of what not to include in your CV you'll quickly find out there's absolutely nothing you should put in your CV. Critically consider what you read suggested about what a good CV looks like and make your own mind up based upon the supporting arguments made and your own CV's feedback. For example if you disagree about point two and decide to include an 'interests section' ask recruiters when they call you what they think about it, did it provide value or was it noise? If you're getting interviews ask the recruiters what in your CV is standing out. If you're not, then ask what, if any, feedback there is from the client - and react to it.
I really do think of a CV like program code or a developer's utility. As a good developer you always need to evaluate your tools to ensure they are providing the maximum value. And like program code there is always an element of entropy to catch and counter over time. A CV, like program code, can sometimes be brittle and break with additions. Using and maintaining one is a matter of constantly reviewing, refactoring and responding to user feedback. For some good resources on CV writing I really recommend the following links: http://www.harveynash.com/uk/hnit/jobs/articles_cv_basics.asp http://www.lifeclever.com/give-your-resume-a-face-lift/ And for graduates especially: http://www.kent.ac.uk/careers/cv.htm