Tips for Improving your RSE CV

Posted by Ian A. Cosden on September 22, 2020 · 6 mins read

This is a crosspost from Ian A. Cosden's Blog, Ian Cosden's Personal Blog on RSEs and Other Things. See the original post here.

Note: This is part 1 of a series with tips for getting on the short list for an RSE interview.

Your CV

Hiring is one of - if not the - most important part of my job. It’s a priority and I have every incentive to get it right. I want to find someone good. No, I want to find someone great. As a rule I look at each new applicant excited and hopeful. I give everyone the benefit of the doubt. However, I’m really busy, so I simply don’t have time to spend 15 minutes on each application. I probably have 2 minutes to skim a CV. So it’s in your best interest to make my review as easy and quick as possible. Remember, the point of a CV is to summarize your experience/education in a way that demonstrates that you are qualified for the position. Once you make the short list, the CV becomes significantly less important; your performance in the subsequent interviews will trump your CV. It might help to consider that the goal of your CV is to get a hiring manager to say “I want to talk to this person.” I’m not going to address how to go about building a quality CV - that’s the topic for another post. Rather, let’s assume you’re already at the application process. There isn’t time to go out and do something to beef up your CV, so instead we’ll work with what you have.

CV Tip #1: Use formatting to your advantage

I don’t have specific advice here, because there are an infinite number of ways to do it effectively. There are lots of resources online too (for example here and [here(https://www.freecodecamp.org/news/writing-a-killer-software-engineering-resume-b11c91ef699d/)]). Your goal should be to make sure that on my quick initial skim I can see your relevant skills/experience/education quickly and clearly. I’ve seen people use bold in clever ways or have lists on the side with years of experience with certain technologies to make it really easy for me to see. I appreciate when relative experience is clearly articulated. A long list of every technology you’ve ever heard of isn’t helpful, you aren’t impressing anyone, but if it’s organized into buckets like expert, proficient, familiar, etc., it’s much more useful.
Use headings and sections wisely; if things are organized illogically or scattered, the likelihood that I miss something is high.

CV Tip #1a: Get the important stuff on page 1

For an RSE position, research experience and programming experience are both incredibly valuable. I always start at the top of page 1, and work my way down. If you wrote a 100,000 line code that’s being used by hundreds of people, hit me with that early! If you’re in your second year of a postdoc, I’m going to assume you’ve got the research part down; don’t bury your programming experience/expertise on page 4 after pages of publications and presentations.

CV Tip #1b: Don’t put walls of text

Half a page of size 10 font about each project without any special formatting makes skimming hard. This is a good way to convince me to just skip over it. Keep it short, highlight the key features, and move on. More isn’t better, better is better.

This is a great opportunity to jump to the top of the pile. An RSE is a type of professional software engineer. It’s no secret that I like the RSE-chef analogy. Would you hire a full-time personal chef having never tasted their food? At some point I’m going to need to see that you have the technical skills to succeed. When an applicant puts links to code for each project, or a link to a personal GitHub/GitLab/BitBucket profile I ALWAYS click on it.

Yes, always.

So keep this in mind if you link a GitHub profile with literally nothing there. There are many reasons why you might not have anything (you work in private repos, you use local instance of version control, proprietary code), but unless you address that in your cover letter, it’s going to be hard for me to not assume. Honestly, not posting a link to a GitHub account is probably better than posting a nearly empty one.

As I said in tip #3, I always click on links to code. I usually click on personal web pages. I never click on LinkedIn profiles (I have your CV in front of me, why go to LinkedIn?).

Notice that I’m using the word click. Nowadays (it wasn’t always like this) I rarely print CVs in the first round of review. Assume that I’m on a computer with the ability to easily click links. If you have a URL, make sure it’s hyperlinked, it works, and it’s correct! Don’t use too many hyperlinks. Figure I will click on one or two, so use them as a way to get me to read more of what you want to showcase. Used correctly you increase the amount of time I spend on your application and greatly increase the amount of information you can communicate.

Next up part 2: The cover letter