Software Engineer Resume Handbook

resume_handbook

Software Engineer Resume Handbook

Introduction

Many Software Engineers would rather ignore their resume. It reminds you of how few companies get back to you when you apply. But when you are looking for a new job, you end up scrambling to update your resume. Hopefully, this writing will help you create a resume that gets the results you want. 

Important Sections

Your resume has five important sections contact information, your education, work experience and skills. If space allows a personal projects section and goal statement can be added. 

Contact information

For contact information you want to include your name, email address, phone number and the city you live near. Recruiters will contact you by phone or email. Including your actual address is unnecessary, simply state the city you are in ex. “Miami, FL”. Recruiters are never going to physically mail you anything. They just want to know whether you will need to relocate or not.

Education

In the education section you want to list which college you went to, the year you graduated and your GPA. If you have a relevant masters degree list that too. I took my GPA off after a few years of industry experience because it was under 3.0. After five years in industry it is probably best to remove your GPA even if it is a 4.0. By that point in your career your GPA is irrelevant compared to your experience in the workforce.

My education line looks like what you see above. It includes the university I went to, what I majored in and the year I graduated. Since, I have a Minor in Computer Science it would be worthwhile to list it above.

Do not list the classes you took unless you have nothing else to fill space. In general companies do not care what classes you took as long as your major was computer science, software engineering or something closely related. 

If you went to community college and then transferred to a university, you do not have to mention community college.

Your education section should be very short. Five lines at the longest. It should be easy to skim past without thinking about. When the recruiter is skims your resume she should think “ah, the candidate has an appropriate college degree”. 

Experience

The experience section is the most important part of your resume. It should be the largest and clearly visible in the top half of your resume. This section is where you convince the hiring manager to interview you. Many companies will post a general job posting for a ‘Software Engineer’, then depending on your experience and interview performance they will decide to make an offer for a particular level like Junior or Senior software engineer. 

I like to split the experience section up by job. Then have a small paragraph for each project at that job that I want to highlight.

You want to fill the section with the highlights of your career. When did you demonstrate the most leadership, technical acumen and success? That is what you put in your experience section. 

Some of your experiences will have been bad. Projects fail, people get laid off, etc. A simple rule of thumb is “never volunteer negative information”. This goes double for your resume. Never include negative information in your resume. 

If your GPA is bad and you barely graduated college with a 1.5 GPA, do not put it in your resume. If you failed Calculus 2 three times do not put that in your resume. If you are a felon and do not have a legal obligation to disclose your criminal history, do not put it on your resume. If the company wants to know they will ask you.

Were you fired from your last job? If so, do not put that on your resume. 

Employment Dates

All you need to include is a range of months during which you worked at the job. Do not put January 13, 2017 through March 5, 2018 on your resume. The recruiter does not care how many days you were employed at a job. Put January 2017 – March 2018 as your employment date range. If the recruiter cares they will ask you about how many days you were employed during a phone screen. 

Do not say anything negative in your resume about any of your jobs. You might think a job was a horrible failure that you were glad to escape after a year. But your resume should describe that job as a successful stepping stone where you shipped desperately needed features to hungry customers. 

This blurb implies a number of things. I say that I led a team, mentored developers guided the architecture of a project and that I did so with Go, React.js and AWS. I do not say that I have soft or hard skills. I say that I used soft and hard skills to do useful things. 

My friend had an internship which he hated, where his job consisted of writing scripts for his gaming mouse which scraped insurance company websites to check customer eligibility. He wanted to gloss over that internship because he hated it. I had to challenge him on it because even though he felt the internship was a failure it could be phrased as a massive success. How many people help hospitals verify patients’ insurance during an internship? In my internships we built internal tooling that maybe 3 people ever used. My friend built a system that verified insurance coverage for hundreds of people. But he didn’t want to list that on his resume because he remembered it as a horrible experience. 

In this example I included two projects that I worked on while I had the title “Java Developer” at a company. 

You should include non-technical jobs

Include as many jobs as you can fit into the Experience section. If you have one programming internship and three jobs where you worked as a dishwasher, list all of them. Add a short paragraph describing what you did and learned at your non-technical position. Wait until you have had four technical jobs before you remove non-technical roles from your resume. 

Skills

The skills section is often highly positioned in engineers resumes. We value the technologies, languages and frameworks we have mastered and want to put them on top. Resist that urge. The tools you have developed skills with probably only overlap a little with the stack used at your next job. Put the skills section near the bottom of your resume. Do everything you can to make it as small as possible to free up space for the experience section. 

Hiring managers do not get a lot of value out a simple list of technologies you are familiar with. Unless you are a perfect match they will have to spend months training you on their technology stack. 

Unless you are a serious expert on a technology do not list a skill level. You are not ‘Advanced’ at Java or Object Oriented Design or anything else in your ‘Skills’ section. 

Companies are looking to fill positions for generalist software engineers and hire experts to solve particular problems. If you are an expert on a subject your resume should be focused only around your expertise in that one thing. A Cassandra database expert should not be looking for general purpose software engineering jobs, he should be focusing on jobs that want a Cassandra expert. 

As a Generalist you are expected to be able to muddle through any problem that is thrown at you. Companies will throw you at whatever they want no matter the ‘level’ of expertise you put on your resume. 

The hiring manager has better visibility into what the average skill level is than you do. You could list yourself as a ‘Kubernetes – Beginner’ and be the most knowledgable person that company ever interviewed. Only people who do dozens of interviews a year have the visibility necessary to compare you to the rest of the job market.

Some people worry about being ‘grilled’ about anything they list in the skills section. So they try to protect themselves by putting ‘beginner’ or ‘intermediate’ next to the skill under the belief they will be grilled less. If you are a junior engineer, people know you are not an expert at anything. Becoming an expert requires a lot more effort and time than most junior engineers have invested into software engineering. Even if you put ‘Expert at distributed systems’, recruiters will see your two internships and they will not believe you. If you get asked about something admit what you do and do not know. If you are backed into a corner, just say “I know a little about that technology, and I am looking for jobs where I use it in my work.”

If you are an expert in something you do not want to put it in your ‘Skills’ section, put it in the ‘Experience’ section!  If you gave a talk on Kubernetes at Kubecon, that gives you enough expertise to interest people. Do not relegate an interesting experience like that to the skills section. If you were the Java performance expert at your last job then relate an experience where you saved the company hundreds of thousands of dollars in hardware costs. Don’t list actual expertise, tell a story about it. 

Aim to list twenty skills at most. You want to be able to talk about them all intelligently. More skills is not necessarily better, the recruiters is looking for a few keywords that match the job posting. Your goal for the skills section is to give the recruiter the keywords they are looking for and to hint at the breadth of your skills.  

Goal Statement (Optional)

The goal statement is a short paragraph that you can use to help the hiring manager understand what you are looking for. It can be helpful when applying to companies that make general job posts for ‘Software Engineers’ and then rank candidates based on experience. Use the goal statement to let them know what role and grade you are looking for. 

“Senior Software Engineer building today’s software products and platforms, training developers to maximize their abilities, and supporting business success.“

The line above is one I have used. It gives an idea of what role I am looking for and how I view my role in a company. The goal statement is optional, you do not need one. If you are short on space cut it and devote more to the experience section. 

What about Personal Projects?

Personal projects are not one of the major sections on your resume. I include links to my github and blog where people can find my personal projects. I would prioritize describing personal projects before hobbies, but describing job experience is just better. If you have a bunch of personal projects and only one job or internship, make sure to use more space describing that job than you do on your personal projects. 

Style

Styling a resume is a worthwhile, but risky process. Unless you are looking or jobs as a designer or creative artist, showcasing your artistic talent is not going to contribute to getting a job. Hiring managers and recruiters are skimming through dozens of resumes at a time. Your first priority is to make sure that the important sections are easy to find on your resume. Use bold headings that make it obvious that this section is about your education and that section is about your work experience. 

You can add flair to your resume to help standout. Try to avoid anything fancy, a resume is not art. Any flair should be evaluated on whether it makes your resume more difficult to read. Unless you are 100% sure your flair does not make your resume harder to read cut it. 

Sentences with Trailing words

Watch out for sentences with trailing words. Those trailing words are taking up an entire line that could be describing your experience. Try to modify that sentence to use less space or to completely fill two lines in your resume.

Trim Extra Space

Trim as much extra space as you can. Careful formatting can save you dozens of lines in a one page resume. 

Cover Letters

Cover letters often come up when people discuss job applications. A cover letter is a one page letter you write to persuade a company to interview you. You want to write about why you are a good fit for the position and how you are motivated especially to work at that company. 

Two major strategies you can use are to write a custom cover letter for each job you apply for or to maintain a template cover letter which you modify a little each time you apply to a job. 

I use a cover letter template for the majority of the jobs that I apply for.  I maintain a ‘Application Developer’ cover letter and a ‘Devops Engineer’ cover letter then do a little customization for each position I apply for. The jobs I am qualified for are generalist Software Engineer and Devops so my cover letter do not need to change a lot. 

Custom cover letters are good for highly competitive companies and positions that you really want. The problem is that you will end up spending several extra hours for each application and still might not get a response. 

Always squash before opening Pull requests

When you are working on a feature it makes sense to make incremental commits as you proceed with the work. Then when you are done you want to just open a Pull Request and wait for approvals. But it is important to squash your commits into a single commit before merging  into the master branch. The reason is if you need to revert your code change, you can revert a single commit and move on. You don’t want to be in a position where you have a serious bug in production, and you are trying to figure out if you reverted all of the commits. Save yourself the panic and trouble by squashing before you commit to your master branch. Some services like github will automatically squash for you, use that feature if you have it. 

Useful git commands for squashing

# git --amend amends your last git commit 
git commit --amend

# rebase is the command used to actually squash commits 

# git rebase -i HEAD~4 rebases the last 4 commits including the head commit
# the -i toggles interactive mode which opens an editor
git rebase -i HEAD~4

When you run the command git will open a text editor that asks you to choose what to do with each commit.

Example screen when you start an interactive rebase. All commits are picked by default.

The default is the vi or vim editor. In this window you want to change the command for the commits you want to squash. 

Interactive rebase menu

Then the next window will give you a chance to modify the commit message for your new combined commits.

Update the commit message for the squashed commits
Final commit after rebase

Prettier: Automatic code formatting for the Javascript ecosystem

I do most of my work in the Go ecosystem and rely heavily on the go fmt tool to maintain style consistency across the team. But the javascript language does not have a formatter built in so we have been relying on jslint to enforce consistent styles.  I found a auto-formatter for javascript prettier, which could make frontend formatting much easier you can find it at https://prettier.io. Prettier supports JSX which is key for us since we work on a single page application with a react.js frontend. I have added prettier to my crypto-exchange application https://github.com/Sevii/pepper-exchange to evaluate how well it works.

I dislike using linters to address code formatting and style questions because they basically nag developers into formatting things correctly.  Code formatting is low value work, I would much rather have a machine do it in 250ms  than have a developer spend 60 seconds addressing linter issues. 

Prettier should let us eliminate formatting nagware, and limit our use of jslint to semantic and correctness issues.

You can use prettier as follows. 

yarn add prettier --dev --exact

# or globally

yarn global add prettier

prettier --write "src/**/*.js"    # This command will format any .js files in your src folder.

Git hooks for Go fmt

A common problem when reviewing pull requests is large diffs of formatting changes. You end up with pages of formatting changes that people waste time looking at when in reality it was just a 3 line PR. Go has a tool called fmt which can format any Go code into the standard Go format. What happens in my project is that some of the team has their IDE configured to automatically run go fmt when they save a file, while the rest do not. So our codebase is in an inconsistently formatted state. What I am attempting to do is to setup a git-hook that will run go fmt before any commits.

The .git/hooks directory contains samples of git hooks that can be triggered on various git actions like pre-commit, post-commit, post-receive, etc. The files need to be executable, with no extension and named after the appropriate hook. This digital ocean link has a table of the available hooks if you scroll down a bit https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks#basic-idea-with-git-hooks. 

The hooks are just executable files and it may be possible to run compiled binaries as well as shell scripts. Here is my working go fmt pre-commit hook. I edited the example script in .git/hooks/pre-commit.sample to run go fmt and renamed it to pre-commit.

 

#!/bin/sh
#
# A  hook script to verify what is about to be committed.
# Called by "git commit" with no arguments.  The hook should
# exit with non-zero status after issuing an appropriate message if
# it wants to stop the commit.
# This hook runs 'go fmt ./...' on the project
# To enable this hook, rename this file to "pre-commit".

if git rev-parse --verify HEAD >/dev/null 2>&1
then
        against=HEAD
else
        # Initial commit: diff against an empty tree object
        against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
fi

# If you want to allow non-ASCII filenames set this variable to true.
allownonascii=$(git config --bool hooks.allownonascii)

# Redirect output to stderr.
exec 1>&2

echo "Running go fmt"
go fmt -x ./...

 

 

Here are some further references.

An Example Git-Enforced Policy

https://git-scm.com/book/en/v2/Customizing-Git-An-Example-Git-Enforced-Policy#_an_example_git_enforced_policy

Pre-Commit    NPM based git-hook installer https://github.com/observing/pre-commit

Githooks 

https://githooks.com

Using pprof to examine the heap and memory usage in Golang Programs

I had some trouble getting the info I needed to setup pprof in my program. And figuring out the steps to get actionable data out of pprof. So here is my attempt to provide the minimum steps needed to use pprof.

Instrument your code

import (     
   _ "net/http/pprof"         
    ) 
func main() {     
   go func() { log.Println(http.ListenAndServe("localhost:6060", nil)) }() 
//Your program 
}

Make sure you have the above in your main.go file. This sets up a webserver that provides pprof data at the below link.

localhost:6060/debug/pprof/

Heap Memory Usage

In your shell run: go tool pprof http://localhost:6060/debug/pprof/heap This will open a cli program, enter top into the prompt.

go tool proof http://localhost:6060/debug/pprof/heap

This gives you the top 10 nodes of memory usage. It will truncate the results if most of the memory is in the top 3 nodes.

CPU time

To sample 30 seconds of cpu time, with 50ms of time ‘sampled’. go tool pprof http://localhost:6060/debug/pprof/profile

go tool proof http://localhost:6060/debug/pprof/profile

    pprof Godoc:   https://golang.org/pkg/net/http/pprof/