Resume Feedback

Writing a Resume

As I've continued to update my resume over the years and as I've become more involved with interviewing developers for both my teams and other teams, I've become increasingly opinionated around what makes a "good" resume. I think a "good" resume is incredibly subjective and evolving, and I don't think I'm an expert by any means. That said, it seemed worth collecting my thoughts on what I think makes a resume effective.

Writing a resume is its own skillset and can be frustrating because of how much you can iterate on how little. Fortunately we get lot's of practice as we update it over the years. I think it's worth spending that practice time being reflective and intentional. That investment not only creates a hopefully nice looking document, but also allows you to think through elevator speeches, "a little about yourself" intros, and responses to interviews.

General

Who is your audience, how do they use resumes, and what do you want them to feel/think after looking at yours? It's worth thinking about these questions every time you work on your resume. A resume that makes you look great is nice, but the best resume gets you an interview because you look like you'll solve the potential employer's problem, whatever that is.

For me a resume is something I'm immediately skeptic of; something I'm expecting to be lied to in and something I'm looking for reasons to dismiss a candidate. There are 'triggers' I'm looking for to switch gears and then 'root' for a candidate, until I find red flags etc. For an employer a resume is a filtering tool to dismiss candidates before wasting time interviewing a bad fit. I'm looking to find unsupported claims or lazy work masquerading as passion.

At this point I strongly believe every developer that's not already established in their career should have a website. Creating a web page is so easy to do and host these days, and it creates a portable resume and place for self expression. If you don't have your own website (even if you're a predominantly back end developer) I question if you're really "passionate" about development. You should put your resume on your website. This makes it easy for someone to always get the latest copy of it, and ensures it's easy for you to grab a copy at a moment's notice.

On your website, you can 'frame' your resume with text around it / make it a focal point. Then you can link to your website from github, linked in, email, and any other 'funnel' that you have. Just like SEO and selling a product, you want to have channels that lead employer's to click "buy" on you.

It used to be that 99% of the time a resume was printed before being read. These days it's probably 90% digital, but it's still good to make sure your resume is printable. That said, I like putting a QR code on my resume so if they do print it, they can scan the code to get back to my site. (You should also have your website written out on the resume).

I don't know anyone else that does it this way, but my resume is written in html. This gives me full control over exact display / placement, makes it easy to version control, helps me keep my web skills sharp, and is easy to convert into a pdf by 'printing to pdf' from chrome. It's also just a lot more pleasant than trying to format a word doc.

A resume is a time to be really anal and consider every word. Everything from layout to what story you're trying to tell is important, and you'll be fiddling with and incrementally improving it possibly over decades. (This is another great reason for version control. It's nice to compare to older versions and see your evolution).

Here's my resume for reference. I think my resume is currently a bit overcrowded, but otherwise hopefully it's an example of what I'm suggesting / what my opinion of a resume should be.

https://austinkucera.com/assets/resume.pdf

Layout

Resumes are generally looked at in batches. The resume has to make it through a recruiter and then often goes to a higher manager and tech lead. Lots of eyes are looking for a reason to not waste precious time interviewing or bringing an entire team in to interview a dud. Consequently, each pair of eyes is skimming the resume for green or red flags. If I see enough red flags I'm not even going to read the big chunks of text.

A resume that is multiple pages feels like an insult, as it's not the norm and indicates the candidate doesn't value my time. Large blocks of text are insulting in the same way, at a much lower level. A good candidate's resume makes it easy for me to evaluate them, just as a good employee is easy to manage. I want to make my boss's job easier, and that starts with a resume.

A resume that has a crazy font or layout tells me the person is not used to interviewing and/or is not professional; it's an easy reason to skip that person and focus on the others. A good resume stands out, but only slightly. It catches my attention because it feels clean and well designed. It feels readable and welcoming at a glance. Much of this has to do with proper spacing and is reflective of good web design. Sections should be skimmable and my eye should fall on the most important pieces, just like in a painting.

Generally I stay away from color in resumes due to them often being printed. A nice, single color can highlight section headers and provide anchor points for the eye, but should be previewed in grayscale to make sure they still look ok when printed.

Common Flags

I read a resume like a newspaper; my eye skims all the sections, goes back up to the name (which I probably initially skipped), swims around for a github, and then often goes there before looking at the rest of the resume. A site or github tells me what they've done, and is more 'honest' than what they say they've done. After that I look at most recent experience first and scan for accomplishments over participation and my list of green and red flags. At that point I start building my case / bias for why we should skip or interview. This is a guttural reaction and I don't think that's necessarily a bad thing. I should be strongly in favor of interviewing a candidate after reading the resume. If I'm apathetic towards them it's not worth investing further. Reviewing a resume is a messy, subjective, bias filled process. After seeing so many resumes and noticing the correlations in the interview and hired process, interviewers develop an intuition and a set of flags they look for.

If a candidate has a website and it looks well built, they have clear non-trivial hobby projects, and/or they have a github that's actually active, I get really excited because it's clear this developer is actually passionate about what they do, which is about the biggest green flag I can find in a resume. I'm also looking for "accomplishment" instead of "participation" language. I'm looking for a candidate whose experiences are filled with how they accomplished or delivered value instead of how they filled a seat or did exactly what was asked of them. This indicates that they're hungry to succeed, that they can lead and self start, and that they can communicate at a level above the weeds they're currently in.

On the other hand, there are a number of red flags that quickly bias me against the candidate. Any time I see that the developer has had a single language career, has spent five or more years in a single company (or worse single role) I assume that developer is stale, unmotivated, or a slow/unengaged learner. Exhaustive lists, whether of technologies known or experiences had are also a turn off. They indicate to me either a lack of respect for my time, or an indicator that the candidate is trying to bluff / overwhelm me. I'd rather see a much smaller lists of what was accomplished over those experiences or built with those languages. Lists of technologies used also don't indicate to me how strong the candidate is and often in the interview I find there is very little knowledge of most of the languages listed. I'd much rather a list of projects (and their language) that I can verify myself. I also have a knee-jerk reaction to listing EE technologies like Spring with great aplumb. Often it's meant that they've only used EE frameworks and usually blindly implement patterns instead of thinking through and understanding architecture. In general anything that indicates big business bureaucracy often means the candidate is less agile, self start, and able to think outside of rigid instructions.

Content Tips

Can you reduce your opening paragraph to a tag line? Can you reduce your experience bullet points from two sentences to one? If need be, you can (and should) increase font size to something that's nicely readable. Less words is better for a resume, especially if you can distill the essence of what you want to communicate. When you've done a good job, you can lift phrases straight from your resume to respond to questions in interviews, and if you've spent that amount of time, you'll have those phrases memorized.

In the pdf version, anything that can be linked to should be a hyper link so someone can easily verify your claim. Your website, github, email, and each specific project should link to its web page. Given you have the space you can also spell out the address or similar for your projects for the printed version, but so long as the hyperlink prints normally it should be enough to just make existing text link properly. This lets someone who is interested verify that your projects are solidly done etc.

Wherever possible replace "I did" or "I completed" with "I accomplished" language. "Participated in Hackathon" tells me you showed up, but I don't know if you were a help to your team. "Lead team in Hackathon" or "Won best in Show at Hackathon" or "Completed Playable Game at Hackathon" tells me that you weren't just showing up, but also pushing things forward. Even better if you can link to the project, and better yet if they can see it running/play it. Employer's don't want someone who shows up to work on time and leaves at the end of the day and was a warm body in between; they want someone who will push to get things done without being hand held. Any opportunity you have to show you're that latter person will make a potential employer more interested in you. I don't care that you worked at a place; I care that you accomplished things for that place, because I care that you'll accomplish things for me.

This is something I do bullet point by bullet point when I'm updating my resume. I look at each line and make sure it's stating what I accomplished by doing something. This says that I not only learned the tech or did what I was hired to do, but also how I exceeded expectations in a way that mattered to my employer.