A programmer's resume

Aug 31

Up to this point I’ve used Google Docs for hosting my resume. After all it is cloud based, available from any computer and phone with an internet connection. Using Google Docs I may convert my resume to whatever format I like. Google Docs is great, but I’m a developer and using something like Google Docs, Word or anything like that would not be very developer-esque of me.

Free the files

Google’s format is pretty hidden. One cannot download a “Google text file”, instead one can only convert the files to other standard formats. This will not do for a developer, therefore I decided to write my resume in Markdown.

After some editing I ended up with something like this:

John Mikael Gundersen
=====================
Experience
----------
**Senior Something**, Company 1
I made software
 * I did a thing
 * I also did another thing
 * I was responsible for something
**Programmer boy**; Company 2
I made software
 * I did a lot of things
Education
----------
**A course and degree**, At some university (2010 - 2014)
**Some other degree**, Some other school (2009 - 2010)
Skills
---------
**Some skills:** Skill one, Skill two

Markdown is great, but most HR departments won’t accept it as a valid format. There is an argument to be made that one shouldn’t apply to companies which don't accept Markdown, but that is a debate for another day.

Pipeline it!

What would a developer resume be without a pipeline? Nothing I’d say! In the year 2020 everything should be attached to a pipeline of sorts. Same goes for version control. I decided to chuck my resume on github, and github actions seem like a reasonable option. After all I am currently paying for 3000 minutes each month and it would be wasteful not trying to spend as many minutes as possible.

I’m not going to go through the pipeline script in detail, as that would be more effort than I can manage. If you are interested it’s on github.

Generate HTML

First step in the conversion between Markdown and other formats would be to generate a styled HTML document. This document will serve the basis for other formats, as well contain my desired styling. The goal is not that each format should be identical, but that the styling is close enough.

To do the conversion I decided to use Pandoc. I also found a style for the resume which I enjoyed quite a bit. The original can be found here. My version is pretty much the same with some very minor tweaks.

When Pandoc has done its thing we end up with an HTML file with embedded styling.

Making the conversion wasn’t any worse than adding this to my GitHub Action script:

- name: Markdown -> HTML
        uses: docker://pandoc/latex:2.9
        with:
          args: --include-in-header style.css
            --output=output/resume.html
            resume.md

Generating PDF and DOCX

The second issue is generating the more “appropriate” formats.

PDF might be the most important format. Luckily I found weasyprint which does this job effortlessly:

- name: HTML -> PDF
        run: weasyprint ./output/resume.html ./output/resume.pdf

DOCX is a bit of a tricky format. It is very much tied to Microsoft and Word. To do this I had to install libreoffice in my pipeline, which does take a lot of time. It’s not perfect, but it gets the job done:

- name: HTML -> DOCX
        run: |
          libreoffice --headless --convert-to "docx:Office Open XML Text" ./output/resume.html
          mv resume.docx ./output/resume.docx

Distribution

What would a developer resume be without versionised release? Very little. Therefore I added a step which automatically bumps up version number and adds the various files to the latest GitHub release.

The added benefit of this is that I now can statically link to the latest release which always will be up to date.

Why do all this?

Mostly fun. I reckon that most employers won’t really notice the difference. Currently I’m stuck between some bigger posts which has taken more time than I expected, so I thought this could be a fun small one to slot in-between the others.

To update my resume I only need to update the Markdown file and all the other formats will be automatically generated. All links pointing to the “latest” release will now point to the new version. Therefore we can say that the deployment of my resume is not automatic. The only thing lacking are tests to verify page numbers and so forth.

The other reason is because I am planning a better “about me” section and I want to try to figure out how to make sure that my resume is always up to date (automatically). We’ll see how that all pans out. Now I just need to figure out how to dynamically linkt to a HTML or PDF document with SquareSpace....

If you are interested in doing something similar, feel free to check out the GitHub repository for inspiration.

Update #1- I managed to host it

I figured out that since I’m already generating a HTML file then I might as well host it on GitHub pages. By doing that I can embed my site as an ifram like so:

Update #2 - Automated tests

What kind of developer would I be if the resume didn’t have automated tests? The tag-line for my resume is that I have a passion for automated testing, and therefore it only makes sense that I would have tests for my resume!

First step is to add tests for the number of pages. Currently I’m aiming to keep my resume on one page only. To make that happen I decided to use pdfinfo and made my own bash script:

#!/bin/bash
cd output;
NUM_OF_PAGES=$(pdfinfo resume.pdf | grep 'Pages' | awk '{print $2}');
echo "Num of pages found $NUM_OF_PAGES";
if (($NUM_OF_PAGES > 1)); then
    echo "Too many pages ($NUM_OF_PAGES)";
    exit 1;
fi
exit 0;

Spelling mistakes may be one of the most embarrassing types of errors in a resume. Therefore it only makes sense to do a spell check. This was achieved by putting a wordlist and spellcheck file in the repository combined with this GitHub action step:

- name: Check spelling
        uses: sbates130272/spellcheck-github-actions@v0.6.0

The last type of tests are verifying that the URLs in the resume actually works and points to something useful. I found this GitHub action which made this check trivial:

- name: Verify URLs
        uses: gaurav-nelson/github-action-markdown-link-check@v1
        with:
          file-path: ./resume.md

So far I believe that this has become a very programmer-esque resume. We have:

Version control (GitHub)
Automated unit tests (spelling check - This one is a stretch of what a “unit test” is)
Automated integration testing (PDF page count, and URL checks)
Automated deployment (GitHub release, GitHub pages)
Pipeline (GitHub Actions)

Is it over-engineered? Absolutely.

Is it necessary? No.

Did I do it? Yes.

Was it worth it? Probably not.

John Mikael Lindbakk