In the past couple of months I have spent a lot of time looking at CVs. I found a new job, hired a replacement for my old job, and helped several friends and colleagues find new jobs.
As an aside: the market for software engineers is correcting from over-demand and under-supply, into a more discerning or critical place. I think this is a bad thing for the individuals, but a good thing for the population. I'm not sure if it's a good thing for the long term or not.
Anyway, here are some things I found myself thinking a lot while writing, revising, and reviewing CVs for software engineering professionals. I was working from junior to senior, and from Individual Contributor (IC) to Product Owner or Manager roles.
- If I see any numbers for anything other than dates, durations, or version numbers i will scream. Name-dropping Angular 2+ or an 95% test coverage: OKAY. Telling me you have 3/5 git skills, or your python is rank 1 of 5 of your technical skills is akin to telling me you're a Virgo. This is a made up scale that you're placing yourself on, stop it.
- Two pages, max. I know, I like to write too.
- Pick a font that isn't a default, make sure it's well-spaced and readable (see also point 2).
- Your personal statement should have something opinionated or controversial in it. Pleasing everyone sounds very generic. Everyone is a "self-motivated problem solver who loves working in teams". It's boring. Tell me that you love brining in Infrastructure as Code, or replacing Low/No Code tools with actual code, or that you love building semantically correct HTML. Yes, this will put some people off, but you don't want to work at any company, you want to work somewhere that vales you.
- Go chronologically and group similar things together. Put your academic qualifications first if they're relevant or recent, but don't mix jobs, volunteering, and qualifications. It looks like padding.
- I like seeing genuine hobbies or interests. I think it's controversial, but they're a good small talk starter. Even if they're generic or boring (yes, we all like good food and video games, we're all well-fed nerds). Make them small-enough to be ignorable. Avoid virtue signalling.
- Sell the value you delivered, to customers or the team.
- Telling me that you followed company process is like an actor boasting they learned all their lines: it's a baseline expectation. A bad performance can't be saved with "well at least they memorised their lines".
- Claims that can be evidenced are 10x more interesting. You increased test coverage? Tell me you went from 50% to 70% in six months. You converted a monolith into a distributed system? Tell me that P90 response times went from 800ms to 50ms on the slowest points. You reduced deployment times in the team? Tell me some pipeline times.
- Check for spelling mistakes, then double-check.
- Read all of the document out loud.
- Another spicy take: if you're primarily a web developer, it's probably good to have your own personal website. A website can be an index.html file. Actually, more websites should be index.html files.
- Things that happened long ago, or things that are less relevant deserve less space. Sometimes it feels like people are boasting about being a prefect when they were fifteen.