Show HN: ResumeFodder – Go app for generating Word resumes from JSON Resume data
resumefodder.com
resumefodder.com
The goal for the resume is to get a job. It is something that you create once and update as needed (I'm still using the same resume file started 8 years ago). It needs to stand out from the crowd; with a generator, all resumes look the same.
The templates/examples that are go against some of the basic rules/best practices for resumes (ie too long, too verbose, not easily machine parseable).
If you want to solve a problem in this industry, it would be "how do recruiters find the best candidate" and "how do candidates find the best job for their skills". A resume generator solves neither one of those.
Otherwise, this is a cool fun, hack though. I think there may be better applications for JSON to template to document technology other than resume generator.
Like you, I've been maintaining the same Word document for years now. A pain point for me has been tracking changes over time. Like I said, my work history is pretty extensive... so every couple of years I go back and trim some detail off older listings, to reduce length and prevent my resume from looking like a CV. However, I hate to lose that older content forever, and storing multiple versions of Word binaries and diff'ing them is kinda clunky. Separating the content from the style really helps.
Also, earlier in my career I had to maintain two or three different versions of my resume, to target different types of job opportunities. If I were applying for a more front-end focused position, then I had one resume that put more emphasis on JavaScript and HTML experience. For back-end focused positions, I had a version more focused on Java and SQL. At this point in my career I have much clearer vision of my career path, and know what I'm looking for in my job hunting. Also, we're ALL "full-stack" now, right? (just like all companies are "agile"!) However, if you do need to maintain customized versions of your resume content, then being able to branch in git is awesome.
Lastly, I just like the ability to switch up the look-and-feel every so often, without a ton of cut-n-paste hassle. These days I spend more time on the other side of the interview table as a hiring manager. You CAN go too far off the deep end with silly resume design, but I'm here to tell you that a little touch of style definitely makes you stand out from the crowd. Even if it is a canned template. 90% of developer resumes today are ugly blobs with no real formatting at all.
- A "cool and easily editable" (as you've pointed out) CV/Résumé (I graduated last month).
- A little project to work on as long as I was (also) studying Javascript in my spare time.
So I merged these things into a useful (for me) one.
The following sharing of the outcomes, is a thing that IMHO one may or may not decide to do. If one (as @StevePerkins says) add "features" that could be useful for others, then I can't see any reason for prevent him/her from sharing it... even if it's just another fish in the sea (furthermore, one can always become the "big fish").
Pdf is better on several counts, (generally) read-only and an open standard for many years now, therefore having convenient free readers on OSX and Linux, usable without formatting concerns.
Unless the ATS the company you are applying to requires it...
Second, if I had that attitude I would have to pass up a lot of applications. The embedded world is full of companies that are not as current and flexible on hiring practices as the web/mobile world. Especially embedded companies outside SV and Seattle.
The only reason these Word-only folks survive in pockets is because people comply.
I was under the impression that PDF that isn't encrypted is trivially editable, though there is lots of read-only software.
IIRC, its exactly as trivial: you use PDF editing software, just as you use Word editing software to edit a word doc. The only difference is that lots of consumers use read-only software for PDFs, but they aren't -- absent use of specific protection measures -- inherently read-only.
I case anyone wonders, this hasn't caused problems in practice. I push back and explain that I don't have a Word version of my resume (I use LaTeX), and the recruiter will pass long the unmodified PDF after one or two rounds of email.
If a recruiter asks for word, say simply "I don't own Word, sorry."
Yes, the 3rd-party headhunters tend to strip off my contact info and insert their own. I don't really blame them, given the number of companies who try to cut out the middleman and hire the candidate directly (I'd had companies try to do this with me on multiple occasions).
At any rate, it's trivially easy to export a Word file to PDF if you wish. I've seen some other JSON Resume processors that maintain separate templates for multiple file types (e.g. Word, PDF, HMTL). To me it just made more sense to have one version of each template, since you can easily export from that output to all the others. This reduces the burden of authoring new templates.
Never been a problem, and why should it? There are free readers on every platform, which almost everyone needs to have installed to read documentation, if not by default.
All of the source code is published to GitLab (with a GitHub mirror), and is described at:
https://resumefodder.com/source.html
The core functionality is just a couple hundred lines of Go code. The version of the Microsoft Word file format that I'm using is raw XML, and the Go standard library includes a template system that lets me add dynamic tags to the XML. The Go standard library also includes a built-in JSON parser... so it just a matter of reading in the resume data and processing the template output, with a bit of validation in the middle.
I wrote two front-ends for that. One is a command-line wrapper for running locally. I was originally inspired by another JSON Resume processor named "HackMyResume", but it is JavaScript-based and requires Node.js to be installed. With Go, I liked the ability to compile down to a standalone executable with no dependencies at all.
The second front-end is of course the online website that you've viewing. That's only a few dozen lines, and runs on Google App Engine. For this particular use case (e.g. stateless, no data storage or querying), that platform really shines.
I'm not a very front-end savvy guy, so the website static content is just me doing the best I could with Bootstrap. I'm going to have to split some static assets off into CDN hosting... because I'm currently serving EVERYTHING through App Engine, and just blew through my daily free bandwidth quota in two hours. :(
I started from JSON by defining a meta-model with a certain semantic with the aim of rendering it with HTML+Javascript (and using CSS for both online and PDF printed version) but, instead, I should better have checked the web first...
By the way, I really like the "raw" JSON format for the CV/Résumé (perhaps as I have defined it)... if it wasn't for @mixmastamyk point, I'd be glad if it would be accepted as is.