I lost my job at Plan to Eat and I still have bills to pay, so I am on the hunt for a new position! I am specifically looking for a role as an Engineering Manager or Senior Engineer. My coding background is primarily in Ruby and JavaScript, as you can see in my portfolio, but I also have some experience with Python, Swift, and Java. If you are looking for someone to join your team, don’t hesitate to reach out using the social links!
…So that’s the ad.
Given that situation, I wanted to write a series about how things are going in the early stages of my search for an engineering role. I have seen some folks say they found a job a week after a layoff, and I have seen others say it took them weeks or months to find their next role.
This post will focus on writing a resume and what changes I made for my current job hunt. I’d love to hear from you if you found this advice helpful, if you think I’m doing something wrong, or if you think I’m missing something important!
The baseline software engineer resume
I think it goes without saying that updating your resume is a good first step to starting a job search. But resumes are an attempt to address a difficult problem, so they should be considered carefully.
The problem is, how do you effectively communicate that you are an accomplished professional and the best candidate for a role in one or two pages? Worse, how do you do it when you know your resume is one of dozens and will likely be skimmed?
In the past, I have always written resumes by copying how other people in engineering roles do it. From top to bottom:
Contact information at the top (name, general location, email, phone, website, GitHub, LinkedIn)
About Me: a short paragraph about yourself
Work Experience: usually a list of jobs with bullets beneath each describing things you did there
Education: like work experience, but probably less detailed
Skills: a list of technologies or soft skills you feel you are good at
Additional Skills: I tend to include my Eagle Scout rank and First Degree Black Belt for some color
I still have this basic skeleton in my resume, but after doing some research, I came across an Indeed article that convinced me to change it in one key way: by using the STAR method.
STAR: Situation, Task, Action, Result
In the “Work Experience” section, rather than just listing things that I have done, I focused on a few major contributions I have made at each company. Each contribution has a bold headline for readers skimming my resume, and bullets beneath it breaking down the Situation, Task, Action, and Result.
For example, I developed a Nutrition Facts calculator at Plan to Eat. This project took most of a year to complete and was one of the tougher challenges I have taken on in my career as a Ruby developer, so I make sure it is front and center in my resume. But rather than just saying I did it in a bulleted list, I describe it as follows:
As a full-stack engineer, I responded to a common customer request for a Nutrition Facts calculator by developing a "Calculate Nutrition Facts" button.
Developed a service in Ruby on Rails to consider the recipe's ingredients, the number of servings in the recipe, and how to scale the ingredients to match the USDA's units before searching for results
Added a "flag for review" feature so users can notate mistakes in the searching and scaling behavior
Developed a machine learning admin interface to address the flagged recipes and other inaccurate data, allowing for the Nutrition Facts service to improve over time
Received overwhelmingly positive feedback from longtime customers for the addition of the feature
As the STAR principle recommends, I describe the situation (I was a full-stack engineer), the task (developing a Nutrition Facts calculator), the action (writing the service and the admin interface), and the result (customers responded positively in support tickets).
My goal with the bold headlines is to make it possible to skim my two-page resume and still get a few essential bits of information out of it. Maybe the Nutrition Facts calculator is of interest to the hiring manager, but maybe my management experience is more important. Either way, they can read all of the bold headlines pretty quickly and only read the bullets beneath the ones they are interested in.
One or Two Pages?
Everyone’s work history is different. I would definitely not stretch your accomplishments out to fill two pages if you don’t have two pages of content, or crunch a ton of content into one page for the sake of it. I think two pages of easy-to-read content is better than one page of small font and narrow spacing.
For my first two positions as an engineer, I used a one-page resume. I moved to two in my search for a manager or senior engineer role. I think the STAR method and the structure I chose have made my resume detailed, yet easy to skim the content.
But what do you think of my updated resume? Let me know in the comments or on LinkedIn!
Post number 77.