This is the 2nd part of a little series, talking about developer recruitment. The first part can be found here.
Writing a CV as a software developer is a tricky balance; there’s a lot of information to get on there, but most of it isn’t very… interesting. Part of the challenge is that a CV is written for so many different audiences, who are all looking for different things – and these audiences often form gates in a recruitment process. The first reader of a CV will probably be a non-technical recruiter, either internal to a company or an external agent. Typically, this reader is acting purely as a filter, looking for keywords to appear. They don’t necessarily know what ASP.Net MVC or AWS are, but it’s on their job spec, so only CVs that mention it will get through this gate. If an agent was involved, an internal HR person will probably be the second gate; again, they will be looking primarily for keywords, but might look at other things like employment history or communication style. It’s not possible to win a job at these early stages, only to be filtered out. The ratios of CVs that make it through the early funnels can be anything from 10:1 to 100+:1.
When writing a CV, work on the basis that it will be read by a busy person, who will read only while they are interested. If you don’t capture interest in the early parts, and hold it, the reader won’t reach the end. Try to order content accordingly; if you lead with a big list of technologies you’ve used, you are relying on the reader persevering or skipping and coming back to that section. Recruiting managers are normally busy – that’s often why they are recruiting in the first place – so considering this factor can go a long way. No-one wants to read a 50 page CV that has your life story; but the odds are you’ve accomplished too much to fit into a single page. Finding the right balance is something that will take ruthless editing. I open with a personal statement, that is as readable as possible and tries to capture interest with teasers of some of the things I specialize in, and feature longer case studies on a small selection of projects rather than have a blow-by-blow full history of every client I’ve worked with which means nothing. Some agents will insist they “need” a full employment history; odds are they are either working with a very traditionally-minded business, or they are looking for sales leads.
To capture a list of skills, languages, technologies and so on, I go for a table layout. This list is vital in getting through early filters, but for the actual recruiting manager it holds little value. It’s worth thinking about what you put in and leave out; if I’m hiring a senior engineer, and they list things like “Microsoft Word”, it’s not very inspiring – I’ve got non-technical relatives who think a CD drive is a cup-holder but who can find their way around a word processor! You’re trying to show depth and breadth of knowledge, but listing every single npm module you’ve ever referenced in a project is clearly crazy (especially as the number of npm modules needed in a typical project is so crazy). I have a table that I break into sub-sections, grouping things like languages, significant frameworks, build tooling and so on. I start by spamming a list of everything I work with, and filter it until I’m happy with the level of content. I also filter out things that I’m no longer interested in working with; for example I’ve used the TFS source control system, but the less said about that the better, and while I have used VB.Net as a language on projects, I prefer other languages so I leave it off. It’s often worth tailoring this for specific vacancies as well; if you have worked in VB6 for 10 years and are applying to help maintain a VB6 system, it’s a very marketable skill; if you’re applying to a startup who will be starting from nothing, then not so much.
Try to write a CV in an interesting, human, style. I see a lot of CVs where the writer is trying to sound “professional” by writing in the 3rd person and passive voice, and this grates on me immensely. Subliminally, by writing in this style, you are pushing things away from you, which could suggest you don’t believe in what you are writing, or that you feel a distance from it. I think it’s better to show some personality, which means people who think like you do will like your style. It may also mean people who don’t think like you don’t like your style, and that’s ok – if you were to work with them every day, it would be tiring, so mutual filtering at recruitment stage is saving everyone. I include two sections that talk about me, one that talks about me as a professional as an intro, and one that talks about me as a person as an outro. Don’t forget that everyone you work with or apply to work with are people; they have a personality, a sense of humor, hobbies and interests and a life. If you share hobbies and interests with the people who are thinking of working with you, it can be a really cool thing – it gives you a better than average chance of fitting into the team and contributing to a healthy working environment if you are an interesting and sociable person. One of the easiest interviews I’ve ever had as a candidate was just after coming back from travelling; I’d mentioned this on my CV and it turned out the guy interviewing me was just about to go to the same places. Your personality can be a big asset, so don’t try to suppress it in the assumption that everyone is looking for over-polished corporate robots
When talking about previous roles, there’s a tendency to talk about roles and responsibilities, as a mini job description. I’m not interested in what the job was, I’m interested in what you personally brought to the role. Don’t tell me you “wrote code”, tell me about the ideas and initiatives that you contributed, about some mini-project that was particularly cool. Ideally, you are looking to spark interest, and to create questions in the readers’ minds to leave them wanting more – this is one for the interview! When I read the best CVs, I get a picture of someone who cares about their work, and this often comes from the descriptions of how they added value to the teams they have worked with. When I’m writing this kind of thing for myself, I start with from a list of projects I’ve worked on, and I pad these out with bullet points for the things I’m most proud about for those jobs. If there’s a particularly interesting technical stack, that might form a sentence at the end, but generally this is not the most important information. From this, I write a bit about each project, and then cherry-pick the best ones. I’ve made a couple of controversial choices in how I lay this out; I don’t list every project, and I don’t include a timeline or list things in time order, simply because I don’t think these things are relevant. There is limited space to make an impact, and I try to prioritize valuable content. Some companies or recruiters like this, because it shows I’m able to identify value; some don’t. That’s fine, I’m not trying to whitewash my personality into something that everyone will tolerate; I’m trying to be myself and find like-minded people that I’ll positively enjoy working with.
Try to think about what the reader of a CV is really looking for at every stage: they are looking for someone who has the right attitude, who has the right skills and experience, and above all, someone who will add value. Try to make every fragment of the CV answer the question “I will be awesome for your team/company/project because…”.