For the last month or two we’ve been searching for a decent front-end developer to join the Radio Times ranks. My involvement in the project has been coming to a close for a while (due to Radio Times no longer belonging to BBC Worldwide any more) so finding a dedicated resource has been high on the “shit that needs to get done” list.
Luckily, I was given the fantastic task of sifting through CVs from potential candidates.
Now, if your sarcasm detector has just gone haywire then don’t worry, it’s with good reason. You see initially I presumed I would be swamped with all manner of fantastic developers all clamouring for some Radio Times shaped pie. Unfortunately it turned into being a frustrating trek through a vat of Word document treacle, and the bulk of that frustration stemmed from the quality of CVs that fell into my inbox.
I saw some good, and saw some bad. So much so in fact, that I thought I could point out a few recurring themes and hopefully inspire some developers to represent themselves more favourably.
Whatever happens show me some code!
I don’t care if you’ve just burst into flames whilst writing your CV. The last thing your charred fingers should be doing is providing a way to get to your code.
I’m not sure I can convey just how important this point is (admittedly, the topic of spontaneous human combustion might just do the trick).
The amount of developers I’ve witnessed without some form of portfolio is quite baffling. At some point in the recruitment process a technical person (most likely a fellow developer) is going to want to see how good you are; and there is no better way than checking out your code.
Linking to the home page of a site you worked on is not good enough. You may have written the whole site, or you may have altered the heading text in a sidebar. It’s impossible for the developer perusing your CV to know this. Explaining what you did specifically is a possible alternative, but you need to be sure your code won’t be re-written. Especially if someone does it badly.
If you don’t have a portfolio then upload some snippets to GitHub, jsFiddle or even Pastebin (it has syntax highlighting!). Basically, get your code in front of your potential employer as fast as possible. They’ll already be thinking “I like this guy” for making their job that bit easier.
Your entire employment history does not interest me
The web is a fast moving place and a good front end developer has to adapt to new techniques quickly. This usually means we have to drop techniques or coding practices that worked before but are no longer the best way to go.
Think how fast the landscape has changed already. Mobile first development, HTML5 and responsive design are just some examples of technologies and design patterns that have absolutely taken off. Showing awareness of these techniques and embracing them often reveals the difference between a “9 to 5″ developer and someone who lives and breathes their craft.
With this mind I found myself paying less attention to job details more than a couple of years old. Candidates tend to include a huge paragraph outlining everything they did at each stage of their employment history and frankly, knowing how awesome you were at IE6 bug fixing in 2008 is not really relevant now. That’s not to say an employment history isn’t useful (if you worked at Facebook in 2008, you should damn well make it clear!) but it’s unncessary to outline everything.
Include a short summary of your time at older positions, and pile on the detail about all the cool stuff you’ve built in the last year or two.
Keep your skills succinct
Ah, the skills list. A place to spit out every single acronym and buzz word that you can think of. It’ll make you look cool right? No, it won’t.
Limit it to the core skills that you actually use. And for god’s sake don’t list every application you’ve ever opened. I can safely assume you are competent with an IDE and Microsoft Word.
Be prepared for agencies to interfere with your CV
A few times I have seen recruitment agenices add their own front page to a candidates’ CV or even go as far as editing their actual details. This can be a problem because they’ll usually just add keywords and more skills, which of course you have not authorised.
To combat this I recommend sending your CV as a PDF (using the many free services available to convert from a Word document) and also making the file available for download from your portfolio.
Spelling and grammar still count
Don’t rely on your chosen word processor to cover your back when it comes to these two. Read your CV, re-read it and then read it again. Even better if you can get a colleague/friend to give it a vigorously strict review.
If basic mistakes like the difference between ‘there’ and ‘their’ or ‘you’re’ and ‘your’ are peppered all over you CV then you’re only going to create a negative impression. After all, if you don’t take care with your incredibly important CV, what are you like when it comes to code quality?
Make a big deal out of personal projects
Working outside of your scheduled ’9 to 5′ job says a lot about your attitude to front-end development. There is a lot to keep up on in the front-end world. All the new parts of HTML5/CSS3, new approaches to problems being discovered and shared on twitter and blogs, and finding the time to actually practice and learn this stuff. It’s a tricky field to remain competent in, but we do because we love it!
Personal projects speak loudly on a CV.
This is a pretty obvious one but it needs a mention here. Your web of lies can easily be unwound by a few well placed technical questions or a test, and it just makes you look foolish.
The few tips here are from own experiences and are likely not to be hard and fast rules. I will admit that until I actually had to sit down and read through a bunch of CVs I was making a few of these mistakes myself. I simply identified what annoyed me as someone who had to read them all and transferred that experience to my own CV. Annoyingly simple in hindsight.
Oh yes, we found a great UI developer for the Radio Times project in the end. Success!