Resumes – Code for more

Don’t bore me: how to write a technical work history that matters

When I was a kid, I used to work at Pizza Hut in the high-school holidays. I loved doing that — when you were in the kitchen you could get away with eating anything you’d made by mistake, and we made a lot of mistakes.

You end up putting up with a lot of Corporate Bullshit in service industry roles — when at about 16 I switched to doing programming jobs in my free time for my beer and clothes budget I was pleasantly surprised at how much better tech companies treat their staff.

Anyway, as a result, I tend to look pretty favorably on graduates or high-school leavers with service industry experience on their resume. It takes a certain inner resilience to not go crazy working in a kitchen or with customers. But reading your resume: if you’ve already got ten years’ experience programming, I stop caring about the jobs you did years ago, especially the ones without direct relevance to the job you’re currently applying for.

Let’s cover what and how to put together the work history section of your resume.

Which jobs to cover

Your resume is a necessary evil that nobody really wants to be reading. Recruiters will just skim it, the Hiring Manager has much better things to be doing and is trying to get to a decision on whether to bring you in for interview as soon as possible, and the interviewing developers are just scanning it for anything interesting to talk to you about.

My belief is that three pages is about ideal for the resume of a Senior Developer with a long work history. A page of summaries and skills to begin, and up to two pages of work history, if it’s interesting and relevant.

Your most recent roles are generally where you’ll have learned about modern technologies, techniques and tooling, and the experience you’ll have gained at those roles are what will be at the forefront of your mind.

While it’s pretty cool that I worked at the BBC in 2006, and also that I was working on one of the first internet TV technologies, the state of the art back then was CVS and Server-Side Includes. Did I learn anything interesting and still relevant today? Sure: I saw one of the first proper roll-outs of Scrum at a huge company, and learned the hard way that 100% test coverage in a codebase is pretty worthless. But at the end of the day we were still deploying code by emailing tarballs to an ops team.

The amount of time and space I want to use describing that role is much less than a modern gig I’ve done using AWS EC2 containers and Kanban. A new role I’m applying for will (most likely) be using a different technology stack and different techniques from what I was doing ten years ago, so describing that is where I want to be spending most of my time.

In general, I’d:

Go into detail only about the last 2-3 roles you held
Summarize earlier roles as a relevant job title and dates only, perhaps pulling out a couple of skills if you’re trying to show a certain amount of experience with that skill or are going for One Trick Pony
Lump up non-technical jobs as a line item (“A variety of non-technical roles”) unless you’ve got virtually no relevant experience — if this covers many years, you could consider adding “Full work history available on request” instead

How to cover those jobs

We’ve identified which jobs to talk about, but we’ve not yet looked at how we’re going to talk about them. We’re going to take a three bullet point approach to this, trying to appeal to each of the interview gatekeepers.

As a very quick reminder of who they are, and what they want:

The HR Person or external recruiter is a non-technical person who’ll be Ctrl-F’ing through your resume looking for keywords that were on the job description.
The Hiring Manager is usually a senior technical person who wants is looking for experience that’s similar to the job you’re applying for.
The interviewing developers are a random collection of non-professional interviewers who were dragged together at the last minute, and are desperately scanning your resume for interesting things to talk about.

With a cynicism so pure it’s admirable, we’re just going to literally give each person exactly what they’re after, in order, rather than trying to be poetic or particularly accurate.

Facts and figures

Job title and dates are one of the few objective facts on your resume. You need to get them right and be accurate. However we can supplement accuracy with some artistic license. Use two job titles instead of one if the role’s title wasn’t exactly what you wanted (see that linked article, there are legitimate and illegitimate ways to do that).

There’s also occasional mileage in dropping the months from employment dates: Dec 15 – Jan 16 is 2 months, where 2015 – 2016 looks a lot like a year. While you had excellent reasons for leaving after two months, those are generally much better explained in person rather than simply stated by your resume.

So we kick off with job-title, dates, and employer:

Senior Perl Developer / Warehouse Systems Programmer
NET-A-PORTER; 2009 – 2012 (Contract)

Keyword smackdown

I’m not a fan of lists of keywords but we’ll start with that to keep the HR Person or external recruiter happy. The more these match and mention the ones in the job description, the better, and if you’re matching your resume to a specific job you’re applying for, I’d consider trimming ones that aren’t relevant: nobody cares that you’ve used FTP and SMTP as a Python developer.

Did you know? HR software, resume databases and job boards often have embedded resume parsers that will attempt to summarize how many years experience you have with each skill. And recruiters are lazy, so will trust the time-saving software they use. It pays to be explicit: I know that if your skills include AngularJS and React then you also know JavaScript, and that if you’re using Docker then you probably have Linux experience, but a recruiter or piece of software might not.

I like to prefix the work history bullet points with a meta-description, so for example:

Skills used: Perl, JavaScript, Test::More, testing, Agile, Scrum, git, Postgres, MySQL, Catalyst, Modern Perl

Try and find a comfortable balance between spartan terseness:

Skills used: Perl.

… and going overboard with SEO-style keywords:

Skills used: Perl, JavaScript, Test::More, testing, Agile, Scrum, git, Postgres, MySQL, Catalyst, Modern Perl, FTP, Linux, bash, T-SQL, CGI, Test::More::Extended, software testing, Cucumber, Behaviour Driven Development, meetings, Microsoft Office, typing, keyboard, mouse, monitor, programming, programmer, development, developing, INTERCAL, IP over Avian Carriers, Perl 5, Perl 5.14, Perl 5.16, Perl 5.18, Perl 5.20

What did you actually do?

In the majority of programming roles, your job in practice was “X Programmer”. And that’s good, but we should put just a tiny bit more meat on those bones. Mention a major project or two that you were involved in, mention what the company did, and mention parts of that project that you took the lead on or that you were good at. It can’t hurt at all to make your last role sound somewhat like the role you’re applying for.

We’re trying here to speak to the Hiring Manager. When HR asked the Hiring Manager to put together a job description, she secretly just thought she could write “Senior X Programmer” and the right people would apply. The aim with this bullet point is to say that that’s what you are, and provide a small amount of proof or evidence that backs that up.

I call this a Role Overview:

Role overview: Senior Perl Developer helping to design and architect an automated warehousing system for a major e-commerce brand. Employed to help build out their automated unit and internal testing libraries to maximize reuse. Role evolved to general architecture as I worked with a variety of external suppliers, internal stakeholders and other teams.

… and in this one I’ve hit an overview of what kind of job it was (“Senior Perl Developer”), the general context of the role (“design and architect an automated warehousing system for a major e-commerce brand”), and started to embed evidence of skills by highlighting opinions of what it took to do the job well (“maximize reuse”).

What was interesting about it?

So far we’ve put together relevant pieces for recruiters and the hiring manager, but … it’s a bit dull. During the interview you’ll need to show off your technical skills by having interesting technical things to discuss. We can prime for that by pulling out interesting challenges and experiences you had in the role. This is also a good time to show off your knowledge of modern tooling and techniques that perhaps don’t collapse easily down into one-word skills.

Simple man that I am, I like to label this section as exactly what it is: Interesting Challenges:

Interesting challenges:

The system involved interacting with large, caged robots moving around a physical warehouse at high-speed. I developed a queue-based architecture based on AMQ to deal with the natural latencies involved with sending 4 tons of steel to a different location at 60mph

Maintaining 100% up-time during development was business-critical so we used a several-stage roll-out during the migration from manual to automatic warehouse processes; I made heavy use of automated monitoring of events using Riemann to detect developing problems before they had a business impact

The initial automated test system took two hours to run to completion, based on a live database dump. I made aggressive use of fixtures, profiling, and removing duplicated testing paths to bring the run time down to under 5 minutes

It’s interesting to note that when I did the things mentioned in the points above, it was very much part of a team effort. It’s reasonable to take credit for things you did in a role, although I’d be very careful taking credit for things in which you had almost no hand: claiming to have been person developing test fixtures is fine unless you can’t talk at length about it during the interview.

As much as anything this section is about signalling the things you do want to talk about in an interview so that you don’t get asked inane technical brainteasers that the interviewer has just thought up instead.

Final thoughts

If you remember who your resume is aimed at and try to speak to each of those people directly, your resume will be 90% better than most of the ones I receive. Your experience 15 years ago fixing computers at Best Buy is of limited utility when applying for a Software Architect role, and including details of it is a signal that you don’t know what’s important and not. Don’t bore the people who have to read your resume — speak to them directly instead.

Get a programming interview with three bullet points

To get a job, you’re going to need an interview. To get an interview, and then a job, you need to get past the three interview gatekeepers.

Developers are generally in high demand, and recruiters want to move quickly, so your resume is going to get read very quickly.

In my opinion it’s entirely possible for most (qualified) developers to put enough good information in three bullet points at the beginning of their resumes that the person reading it will make a snap Yes decision and just skim the rest of it.

If you don’t put anything outlandish on the rest of your resume, it’s possible to get a programming interview with three bullet points.

Don’t be boring

Summary sections at the beginning of a resume can be a real mixed bag. The problem is that people tend to try and describe themselves in positive terms without saying anything of value. For example:

I am a self-starter and also a quick learner. I am highly motivated, with ambitions to work for a company whose high standards match my own. I am conscientious and experienced in all aspects of software development, including JAVASCRIPT, CGI, and HTML programming languages.

Cool story. But nobody cares, see?

Recruiters and HR people think programmers are weird already. They know that you just mashed together some positive adjectives, and that it signifies precisely nothing.

Actual photo from “Search and Placement! A Handbook for Success” by Nobles and Finkel

Assume the Hiring Manager will be deeply cynical. You’ve claimed a lot of skills they may or may not care about while providing evidence for none of them.

Your future coworkers will just think you’re an idiot for taking the time to write all that self-promoting stuff down.

But with a little work — and by that I mean specifically removing all of the above and replacing it with something else — we can make all three groups happy. We’re going to give each group a bullet point that speaks exactly to them.

Help the recruiter know they’re in the right place

Recruiters and HR people get a lot of speculative resumes from people who aren’t even a little bit qualified for the roles. Network Engineers and Waitresses apply for Node.js roles. Sysadmins who wrote a little bit of PHP once apply for full-stack developer roles. College grads apply for architect roles that need 15 years’ experience. This effect is exacerbated by job sites that allow one-click application to roles for job seekers.

Let’s put that to rest straight away. I want you to repeat the job title they said they were looking for back to them, and throw in one or two skill keywords to show you actually read the job ad. Help them to understand that they are, in fact, looking at a resume for a “Senior Python Developer” by literally writing it down:

I am a Senior Python Developer with 15 years experience, including exposure to Puppet and Chef and JavaScript, CSS and AJAX

The hiring manager wanted a Senior Python Developer, you’ve said you’re a Senior Python Developer in the first sentence. They’re not going to look too stupid if they forward your resume on to the Hiring Manager, given that you have assured them from the offset that you are Senior Python Developer — you’ve saved them from having to do some archaeology on all of the arcane words they don’t understand in your work history.

The Hiring Manager

The Hiring Manager is a little more canny. She doesn’t need to be spoon-fed the fact you’re an approximate match, she can just glance at the skills section and work history for a few seconds.

But those skills aren’t really that trustworthy. It’s easy to claim technical skills on a resume. You can just write them in, 4-7 keystrokes each. The person reading it has no idea if they’re accurate or if the experience you’re claiming really happened.

However you can also provide inline evidence of your skills by showing opinions you’ve formed as a result of having used them. You could write:

8 years of Perl, testing, DBIx::Class, Plack, Catalyst, CGI, Test::More

… and force the Hiring Manager to then go digging around in your work history to find out corroboration. OR you could put a bullet point in your summary section where you provide just a tiny bit of description about each skill to act as a shibboleth to people familiar with those skills:

I’m an active proponent of Modern Perl – I love the power of composing resultsets in DBIx::Class, using Plack to hide web-server implementation details, and the way that Test::Builder-based testing tools all interact well with each other

There are a bunch of great ways to prove your skills on your resume; I wrote a whole article about proving not saying which I’d encourage you to read.

Future Coworkers

The developers who interview you don’t interview people for a living. They have your resume, and they have an hour of time to fill. They will be searching for interesting things to talk about based on your resume. Generally developers also enjoy working with people who have an intrinsic enjoyment of technology.

You can provide interesting things to talk about in the interview as well as showing your love of technology by mentioning interesting side projects you’re involved in:

My personal development projects include an automated cat treadmill using Arduino with a digital signal processing component written in Perl using the Event module

… or …

In my free time, I’m currently working on an app that converts photographs of crossword puzzles in to playable games using OpenCV

… or …

I teach an after-work class to my colleagues in using AngularJS

You don’t have to be building a rocket ship in your garage to have an interesting technical project on the go. The more interesting things you have to talk about, the more passion you’ll show about programming, and the more you’ll end up talking about your technical strengths, rather than solving inane technical brain teasers the interviewers found online.

Summary of the summary

Most people hate reading resumes, and don’t want to go on an fishing expedition through your 7 page resume to find where you mention skills. Put the important things first, and speak to the interview gatekeepers.

Having been a recruiter, a Hiring Manager, and an interviewing developer, a resume that starts with:

Summary

I am a Senior Perl Developer with 15 years experience, including exposure to Puppet, Chef, JavaScript, CSS and AJAX.

I’m an active proponent of Modern Perl – I love the power of composing resultsets in DBIx::Class, using Plack to hide web-server implementation details, and the way that Test::Builder-based testing tools all interact well with each other

My personal development projects include an automated cat treadmill using Arduino with a digital signal processing component written in Perl using the Event module

… saves me a whole bunch of time. The recruiter knows they’re in the right place, the Hiring Manager gets a bit of proof you’ve not completely made up all the words on your resume, and the developers get something interesting to talk to you about in the interview.

Just don’t screw up the rest of the resume.

Developers: When being a one-trick pony is of the utmost value

There are some organizations that are interested in generalist programmers or tech people. There are roles where your technical skills are less interesting than your ability to solve business problems by using some programming magic.

But most programming jobs aren’t like that. Most programming jobs are looking for developers already experienced with the employer’s technology stack to solve the employer’s problems primarily using that technology stack.

Most jobs aren’t looking for Senior Programmers, they’re looking for Senior Python Programmers, Senior Ruby on Rails Programmers, Senior C# Developers or Senior Node.js Developers, or whatever the job-spec happens to say.

And when that’s the case, the recruiter will be speed reading your resume looking for proof that that’s what you can do, and you’ll be really helping yourself by making it clear you fit the bill.

Talk About the Important Things First and at Length

If you’re applying for a Node.js role, and your experience using Visual Basic takes up as much room on your resume as your Express.js experience, you’re doing it wrong.

Heck, if you’re applying for a Node.js role, and your experience using Visual Basic takes up as much ink as the fact that you read (and mostly understood) the Promises documentation once, you’re still doing it wrong.

This kind of thing is common and terrible:

Skills:

JavaScript (7 years)
Java (2 years)
Linux (5.5 years)
SMTP (2 years)
FTP (12 years)
T-SQL (1 year)

If you’re thinking: “Do Node.js developers really list SMTP and FTP as skills?”, the answer is yes. Tragically so.

Only the non-technical recruiter or HR person cares (meet the interview gatekeepers) about a long-list of auxiliary skills, they’ve seen 5,000 resumes like this, and they don’t even know what FTP is.

We’re aiming to prove our skills, not just mention them. And if you’re applying for a Node.js role, the main skill you’re trying to prove you have is Node.js

If you’re applying for a Node.js role, then Node.js should be the first heading on your Skills section, it should be the largest part of your Skills section, and it should be full of proof that you know Node.js.

Stop Complaining, Show Me the Examples

How do we achieve this? Let’s take an example, and then break-down what’s going on:

Skills

NodeJS and JavaScript

Web Development

I have extensive experience of using Express.js, and appreciate its light-weight and unopinionated approach. I’ve found Middleware to be invaluable for inserting debugging code deep into requests, and for composing distinct pieces of functionality into one coherent whole. I have commercial experience using Meteor with React, and find that the publish-subscribe pattern allows for simple-to-reason-about consistency of data throughout the whole application. I have some exposure to AngularJS.

Testing

I have a deep and broad experience with various JavaScript testing tools. Most general testing I have approached with Selenium, but I’ve also worked in teams with an aggressive focus on unit testing with Mocha. Mocha’s flexibility is excellent, although I’ve found the sheer number of ways a test-suite using Mocha can be setup can be a barrier to getting started with a new team. I have some experience building Behaviour Driven Development user stories using CucumberJS, which I like because it forces technical and non-technical members of a team to agree in writing to sets of behaviour.

Quite a mouthful! What’s going on here, and why?

Let’s start with:

I have extensive experience of using Express.js, and appreciate its light-weight and unopinionated approach

One way to present your experiences as proof that you’ve actually used the tooling you’ve mentioned is to form and present opinions on them. It shows the hiring manager that your experience probably really happened, and it also gives the interviewers jumping-off points to talk about with you. If you choose to opine about a subject, make sure you have something interesting to say about it in the interview!

Mocha’s flexibility is excellent, although I’ve found the sheer number of ways a test-suite using Mocha can be setup can be a barrier to getting started with a new team.

It’s always worth showing off your battle scars — what are the insights you’ve gained from your experience? The more interesting problems you’ve encountered and solved, the more useful experience you’re bringing to your new team.

This also starts to get into “contentious opinions” territory — something that will allow you to explore how you have technical debates about the pros and cons of technology with your interviewers, without being too weird. We can double-down on that:

I have some experience building Behaviour Driven Development user stories using CucumberJS, which I like because it forces technical and non-technical members of a team to agree in writing to sets of behaviour.

Many developers have heard of, or dabbled with tools like CucumberJS. Some will have formed strong opinions about it. Interviewers will want to talk about things like these, so if you’ve prepared interesting things to say about it, you can keep the interview on topics which are interesting.

One more quick aside: played with a technology but don’t want to commit to being an expert on it? I like:

I have some exposure to AngularJS

It’ll get you past cursory keyword searches against your resume, while giving you an out if you get a question or two that’s out of your depth.

Finally, you might notice I’ve emboldened key technologies. It looks a bit naff, but it helps someone skimming your resume to pick out the things that are interesting to them.

Two bonus pieces of advice

This is neither the first nor last piece of content about describing your skills on your resume, but I’d like to throw in two other simple tips if you’re applying for an “x Programmer” role.

First: Make sure your previous job-titles align with the job-title you’re applying for as far as possible. If that’s not possible (maybe you’re “Software Engineer II” at your current role), take a look at When two job titles are better than one.

Second: start your resume with a clear, unambiguous mention that the person reading it is in the right place. Applying for a Senior Python Developer role? Have the first line of your resume be:

I’m a Senior Python Developer with seven year’s experience.

You’ll stop non-technical people missing the forest for the trees as they read through your experience.

How a recruiter speed-reads your resume

Long before I was a recruiter, I was a programmer. One of the skill-sets I know pretty well is JavaScript, both back-end and front-end.

It takes me less than a minute to read and make a decision on whether I will send a JavaScript programmer CV / resume on to my clients, which incidentally is about the same amount of time it took me as a hiring manager to screen CVs / resumes recruiters sent me to decide if we’d schedule a phone interview.

If you think that’s bad news, what’s even worse is that I’m unusually diligent. Assume an unknown recruiter is reading your CV / resume even less carefully than me.

With that in mind, there are two things I’m trying to ascertain as quickly as possible about your CV / resume: your technical ability, and your hireability.

Technical Ability

The very basics

Does the CV / resume actually mention JavaScript at least once? I get a non-zero number of applications from waiters with no programming history at all for JavaScript jobs. If you’re a programmer, applying for a JavaScript job, I’m going to assume there is at least a mention of JavaScript on your CV / resume.

Mid-level

Are there previous job titles on the CV / resume that suggest JavaScript development has been a primary responsibility at a previous job? A DevOps person may well list JavaScript as a skill without any commercial experience beyond two line hacks.

Primarily I’m looking for something along the lines of “Full-Stack Developer”, “Front-End Developer”, or “Back-End Developer” + a mention of Node.js. If you’re lucky, I have your actual CV / resume document on hand, but if you’re unlucky, I have a preview of your profile that looks like this:

If you’re in the unlucky situation where you don’t have job titles that look anything like the role you’re applying for, how about writing a few lines at the top of your CV / resume saying explicitly:

“I am a Senior JavaScript developer with 7 years of commercial JavaScript experience.”

Help me know I’m in the right place, and you haven’t just applied to every job that’s even a vague match for your skills.

More advanced

Is there supporting evidence you’re an actual JavaScript dev? A link to your npm profile is pretty compelling even if you’re a DevOps person. Mostly though, I’m looking for auxiliary skills that I’d expect you to have if you’re really a JavaScript developer — build systems like Gulp or Grunt, use or experimentation with languages that build on JavaScript like Flow, TypeScript, or even CoffeeScript.

Do you describe a technical problem you’ve actually solved using JavaScript? “Helped develop the client-facing Widget Tooling” is weak evidence, because who knows what you were doing? “Introduced PhantomJS to allow automated testing” suggests you’ve probably got technical chops.

Testing is a huge opportunity to show you’ve done serious development. Solid developers working on non-trivial systems have generally done some automated unit testing. If you tell me the “Widget Tooling” that you helped developed was tested using QUnit or Jasmine, I’m a lot more convinced you were doing proper development rather than hacky one-liners.

For JavaScript, of course, ReactJS and Angular are also skills that show you’ve mentally tackled at least one large framework. But preferably bolster this by describing problems you’ve solved that show you’ve engaged with and built out the skill, or I may wonder if you’ve just made minor changes to an existing code-base that happened to make use of them.

If you’re going to link to GitHub, pull out projects that you’ve originated (rather than forked), and in the skill-set I’m interested in. I get a non-zero number of applications including a GitHub profile that’s either empty, or just has forked and unedited projects.

In general…

Digging in-depth into what you’ve written is a job for the people who end up actually interviewing you. My job is to decide — preferably as quickly as possible — if you’re the type of developer you say you are, and the approximate level of seniority you say you are. While I do sometimes follow up with people if it’s unclear from their CV / resume, assume I am reading your CV / resume while the fire alarm is going off and I’m evacuating a building. If I have to work too hard to pull the meat from your CV / resume, you’re severely handicapping your job search.

Hireability

Generally the person I’ll actually submit your profile to at an employer is a non-technical HR person. They will be attempting to judge from your CV / resume if you’ll be a good employee. As you can imagine, this is a little tricky from a 2 page document, but they have their own heuristics, and that largely boils down to looking for things that worry them on your CV / resume.

These red flags aren’t likely to be instant rejections, but they’re all going to concern the reader, and that reader gets to decide if your CV / resume will be forwarded on to a technical person who’ll actually understand all the long words on it. So it’s worth explicitly heading off any objections they might have.

Gaps

Do you have big gaps in your employment history that you’ve not even tried to explain?

If your last role was two years ago, because you’ve spent two years traveling the world and finding yourself, that’s fine. Heck, maybe that’s even good. Rather than leaving it mysterious, just explain in the middle of your work history:

Jan 2015 – Feb 2017 – Personal travel (Bali, Chiang Mai)”

Have you been dealing with family affairs? That’s also fine:

Feb 2016 – Feb 2017 – Dealing with now-concluded family affairs

I am happy to provide more details as need in interview

Have you been unemployed, job-seeking, and doing even occasional small bits of work for friends and family? I think it’s reasonable to say:

Jan 2012 – Aug 2012 – Freelancing

While between roles, I spent time picking up small pieces of interesting technical work and sharpening my skill-set. During this time I built a Blah Blah Blah system using AngularJS and blah blah blah

Simply: try and avoid giving the impression you’ve something to hide by not hiding anything. Real life gets in the way of all jobs and nobody’s perfect, but the unknown is scary so be explicit about employment gaps.

Very short roles

Between the exorbitant recruiter fees, provision of computer equipment, general HR process faff, and the time it takes for a developer to be brought up to speed with a new system, hiring someone new is expensive.

If you leave a job 7 months after you’ve started, having contributed very little, you may not represent value-for-money to the employer. Employers want employees who’ll stick around for 2-3 years.

An employment history that shows many short roles suggests you may be a problem employee, or have a very short attention span. It can also suggest you’ve just been unlucky.

Try and explain the reason roles were short:

“Company went out of business after 4 months”
“Family issues forced a relocation after 7 months”
“I enjoyed my time at XYZ Corp, but the career progression to management promised at interview was more ad-hoc than had been described in interview”

If the roles were freelance or contract, be explicit about that. In the UK there’s a culture of 3 to 12 month programming contract roles, and that’s fine, and something very different from leaving a series of roles that were meant to be permanent early. By the way: if you have a contracting background, and you’re looking to move into permanent employment, write this in bold letters at the top of your CV / resume. Otherwise HR will reject the CV / resume on the basis that you’re looking for a disguised contract.

Again, nobody’s perfect, and you can definitely get away with one or two short roles. But if you’ve got many many short roles, try and help me and the HR person understand why that is.

Existing right to work

50% of the applications we receive are for roles that are clear they don’t offer sponsorship, by people who would require sponsorship. They are almost all from India. I am desperately keen to hire Ahmed who lives in London with a Tier 2 dependency visa that lets him work in the UK without sponsorship. But I can do nothing useful for Mehmet who lives in Bangalore and requires sponsorship for a role that doesn’t offer sponsorship. And I get an order of magnitude more job applications from people like Mehmet than I do from people like Ahmed.

Put in big clear letters right at the top of your CV / resume your employment entitlement. Doubly so if there might be any question about it. If you have an address in Miami and have a cell that starts with +1, and you’re applying for a UK job, I will not that work that hard to double-check that you have an existing work right, because *most applicants do not*.

Conclusion

It’s a lovely idea that your CV / resume will be perused over at length by people with the time and energy to carefully decipher your strengths and weaknesses. It’s also fantasy.

I will go back to developers who send me ambiguous CVs / resumes for more information sometimes, or for a particularly hard-to-fill role, but again, assume something is on fire in my office when I’m reading your documents. However, I will always jump with enthusiasm on developers whose CV / resume presents me the information I am looking for quickly and in an easily digestible form.

When two job titles are better than one

One of the very few things that can be fact-checked on your CV / resume is your employment history. That you “pioneered the use of continuous deployment” in your last role is just like, your opinion, man, but that you were employed by XYZ Corp from 17th of February to 9th of September as Senior Widget Wrangler is an objective fact.

And it’s an objective fact that companies can and will check, often as part of a box-ticking background check process prior to you coming on board. Someone in a Call Center far far away from Experian or Equifax will ring around the HR departments of your former employers and ask them to confirm the dates you worked and your job title.

If you’ve lied about how long you worked at a company, you’re going to have a very awkward conversation if the background check says otherwise to your new employer. If you’ve said you were CTO when your job title was “Developer Level 2”, you’ve also got a rocky ride ahead.

But even if your intention is to illuminate rather than obfuscate, the actual characters that make up the job titles in your work history may not be those best optimized for finding jobs for which you are in fact qualified.

A Real World Problem

There are a host of reasons that the exact characters which comprise your job title is so important, but most important here is the reductive approach that both recruiters and recruitment software take to reading your CV.

Here’s a screenshot from SEEK, Australia’s largest job-board, when searching for a Junior Sysadmin.

Note how each candidate has a single job title extracted from their CV. A career of working hard, a well-thought-out CV / resume, and it’s been distilled down to 64 characters. And unless I want to download and read all 600 results returned from searching SEEK, that’s all I’ve got to go on to decide if I want to invest more of my time in each candidate.

Lawrence Webb, the Murex Support consultant, is probably shit-out-of-luck, because I don’t know what a Murex Support consultant is. Murex has something to do with banks, I think, but I’ve got no idea what the relationship is with Sysadmin. The part where he explains how he lovingly uses Terraform to spin up AWS environments of Puppet-managed immutable infrastructure has been elided.

Even when a recruiter is doing their job properly, they’ll be likely skimming CVs, and one of the key metrics they’ll be doing is looking at previous job titles. If you’re applying for a DevOps role and your last job title was “Associate Web Engineer” then you’ll be tempting the lazy recruiter to pay even less attention than normal.

So there’s a problem here:

You can use your actual job title for each role, but then you might not turn up in searches. You might be discarded at the preview stage, and busy (and lazy) internal and external recruiters might not bother reading the descriptive part of your last job description if the job title isn’t an obvious match.

Alternatively, you could use the job title you think you should have, but you’re setting yourself up for difficult conversations a bit further into the interview process if and when a background check is run.

A Sneaky Trick

My sneaky trick for dealing this is to double-up the number of job titles on your CV. Lead with a descriptive job title, but also include your actual job title. Planning and executing a move of 100 servers from a data center into AWS, but stuck with the job title “Site Engineer”? Go with:

“AWS Cloud Architect / Site Engineer”

Managing a development team of 10 people but stuck with “Software Engineer Grade 2”? Let’s try:

“Technical Team Lead (Software Engineer Grade 2)”

It’s accurate, it doesn’t get flagged in a background check, and the real beauty of it is: if challenged on it you can be absolutely and totally honest about it, and about your reasons for doing it:

“The first describes the role I did, the second is the job title I oficially held, which I’ve included for accuracy”

It probably goes without saying that if you’re going to do this, make sure you can back it up: if you’re describing your last role as being “AWS Cloud Architect” and you can’t talk in depth about being an AWS cloud architect, you’re going to look like an idiot in a job interview.

Prefer a descriptive title rather than simply inflating your seniority, and don’t use titles that your current employer offers but you simply haven’t reached: if your company has Senior Developers, but you’re not one, calling yourself a Senior Developer when you’re just a Developer may well invite reasonable challenge.