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.
