For years, I’ve been using a simple Google Docs document for my résumé. This has proven to be adequate to land me my current position at IBM, but it comes with some obvious drawbacks. For starters, Google Docs is not the most open format, and while you can certainly export to multiple document formats, it’s far from ideal. It lacks lots of customization options. Complex formatting, like having plenty of fonts, consistent styles, spacing, and margins is also tricky, having to use the mouse to drag and drop everything to format the document to your liking.
Don’t get me wrong, Google Docs and other WYSIWYG document editors like LibreOffice are very powerful tools, and have their uses, but I’ve discovered just how powerful LaTeX can be. I recently stumbled upon a beautiful résumé template created by Debarghya Das, and decided that mine was woefully inadequate. Seeing what LaTeX is capable of was enlightening, and despite having essentially no experience with it, I decided that I would build my own résumé using the technology. Because Debarghya was so generous as to post the LaTeX source code (including templates and fonts) on GitHub, I was able to use that as a starting point.
I decided I didn’t like the two column layout, so the first thing I did was to reduce this down to one. I began to transfer all of the information from my old résumé into the template and began playing around with the template. Isaac Newton once said “If I have seen further, it is by standing on the shoulders of giants”, and I feel that I wouldn’t have been nearly this successful without Debarghya and resources like StackOverflow and Quora. Through these resources, I found a way to create a perfect three column layout for the technical skills section and discovered how to align the years on the career and education sections to the right. I also looked at the source code and was able to play with things such as sizes of fonts, and I discovered how to embed metadata like the PDF author and title data into the .tex file. Using this knowledge I’ve gained, I was able to build a great looking document, and I decided to share my modifications (with proper attribution, of course) on GitHub. It’s truly wonderful to have a complete edit history of your résumé in a version-controlled repository.
One question that came to mind is how do I share my résumé on my website? I want to have the latest version at all times, and need it to be built from my GitHub repository. The first solution I discovered was a service that worked really well called Latex.Online. Through this service, I was able to generate a build URL that would build my document using their servers, and redirect my visitors to the PDF. This worked great, and I replaced the old document in the navigation section of the site.
Not satisfied with that though, I wanted to take it one step further. One issue with LaTeX.Online, if you can even call it an issue is that you need to wait 5-6 seconds for the file to compile from LaTeX into a PDF. Another is that I wanted to try to build a similar solution myself, and didn’t want to abuse their infrastructure. I decided to use a combination of cron and the texlive packages that I needed to build the document. Unfortunately, on CentOS 7, the operating system I’m currently using, there is no texlive-isodate, so I needed to copy a couple files into the résumé repository as a workaround, but it gets the job done. I’ve added a new cronjob to my ansible project, so the file is rebuilt from git and copied to the website’s directory and added a yum task so the relevant packages get installed when I redeploy my website.
The new solution works amazingly. Every 5 minutes, the repository is cloned using git. The LaTeX document is compiled into a PDF (this takes only a second or two), and the old version in the website’s files directory is overwritten. In order to enable this behavior, I had to add files to the .gitignore file so that there would be no merge conflicts when the main website repository synchronizes. You can view the compiled document here. The document currently includes the date it was compiled, to be able to tell if it is a dated version or not.