Show HN: ResumeFodder – Go app for generating Word resumes from JSON Resume data(resumefodder.com)
resumefodder.com
Show HN: ResumeFodder – Go app for generating Word resumes from JSON Resume data
https://resumefodder.com/
38 comments
I started this project because most of the generators and templates I saw out there are really geared toward entry and junior-level professionals. I've been working for over 15 years now, and have a ton of job records since I started out in consulting/contracting. So my own needs were to reduce verbosity in my resume. That's why I added extensions to the default schema, that allow you to list older jobs with less detail than more recent work history, etc.
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.
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.
So instead of creating a simple tool that solves a specific problem (even if its been solved in other ways) the author should have built a whole startup instead? Go outside.
For what concern me (ref to my reply: https://news.ycombinator.com/item?id=11219018), I was in need of two thing:
- 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").
- 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").
No, you should never send your resume in MS Word format, because it can be readily edited. For example, it could be changed by a recruiter before landing at the hiring manager. Not to mention the proprietary nature of the format and support of "the man".
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.
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.
This might be a regional thing, but in 15+ years I've never once worked with a recruiter (3rd-party or in-house) who didn't ask for my resume in Word format.
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.
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.
It's not even that PDFs make it harder for editing, it's that most recruiters will copy-paste from your resume into a standardized template for that company, and the recruiters are oftentimes so bad at technology or so overloaded with hundreds of candidates that they'd rather go with a Word doc to save 2 minutes to open up something else that might get wonky when you copy and paste it again (bullet points are a good example of differences from PDF to Word in how they're copied).
I've not encountered this often, but when I have (rarely), I've just sent it in pdf, with a "Sorry, I don't own MS Word."
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.
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.
A close friend of mine's been doing some job hunting in a non-technical field. He was just telling me the other day how just about every place where he sent his PDF resume replied by asking him to resend it in Word.
I have not sent a resume out in Word format since perhaps 1995, and it was only once or twice even at that time.
Then you must be from super developed country where every recruiter is techie. I am not, I have seen this many time. They ask MS word format resume. These days I email them both PDF and Ms word.
In what world does it take more technical knowledge to use a pdf instead of a doc? It doesn't--pdf is easier to use for everyone except someone who wants to modify the resume without your knowledge.
If a recruiter asks for word, say simply "I don't own Word, sorry."
If a recruiter asks for word, say simply "I don't own Word, sorry."
Yes, absolutely PDF is better, even without someone's malicious intent. Many corporate HR depts use Microsoft Outlook email. Try attaching the resume as both a Word doc and a PDF doc to an Outlook email. Then open by double-clicking in the email message like a typical user. The Word version goes into a double-paned "reading mode" while the PDF will appear as you intended.
> Pdf is better on several counts, (generally) read-only
I was under the impression that PDF that isn't encrypted is trivially editable, though there is lots of read-only software.
I was under the impression that PDF that isn't encrypted is trivially editable, though there is lots of read-only software.
It's not trivial, unless you mean you are able to find software to edit it. Most people are not capable of doing this. If you run into a recruiter who edits your PDF you should probably bypass them anyway.
Nowhere near as trivially as a Word document.
> Nowhere near as trivially as a Word document.
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.
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.
Indeed. Anybody in the business of handling large volumes of PDFs is going to shell out for Acrobat, and then editing your PDF is just a matter of starting a different application.
My personal experience is that, after sending out a resume in PDF format, many recruiters (~25%?) will ask me to re-send it in Word format so they can edit it. The barrier of "use a piece of software outside the Microsoft Office Suite" shouldn't be a roadblock to anyone, but it is.
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.
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.
Yes, and we really shouldn't encourage edits by a third party that we will not see.
I'd be surprised if PDF editing software is even one tenth as common as MS Office + LibreOffice + Mac Office installs.
> No, you should never send your resume in MS Word format
Unless the ATS the company you are applying to requires it...
Unless the ATS the company you are applying to requires it...
That's a great filter for organizations that aren't worth working for.
First, you think Qualcomm is not worth working for?
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.
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.
If they wouldn't accept a plain text or PDF resume, then yes I would. Treating applicants like this is a clear reflection of how employees are expected to behave once hired.
You have to understand that not everyone works in tech.
It doesn't really matter if they do or not. There are no technical barriers, everyone has a pdf reader installed. It's not 1998 any more where Windows and Office was the only choice. With the rise of cloud computing and Macs there are a significant number of people who have never used an MS product.
The only reason these Word-only folks survive in pockets is because people comply.
The only reason these Word-only folks survive in pockets is because people comply.
I love the site and I love your designs. Very well put together. Would you mind sharing some details about how the app itself is built etc?
Thanks!
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. :(
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. :(
Thanks for hosting on GitLab!
If you already have your work history filled out on LinkedIn, this seems like a handy tool: https://github.com/JMPerez/linkedin-to-json-resume
Sort of related. I launched [Progrez | Great Resumes Made Easy!](https://www.progrez.in/) mainly for myself right now :-) ... it uses markdown inputs
The "funny" thing is that I'm currently working (on spare time) on such a thing for JSON -> [Website | PDF] without even knowing the existence of jsonresume.org etc.
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.
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.
Yay, another resume generator site. I thought this was an update to one of the many other resume update apps/sites/(scratch-my-itch-ware)...but this is yet another one. You'd think this was the #1 problem of humanity with all the resume creator/generator/parser code being written out there.
Where does that obsession with Go comes from?
Where does that obsession with JSON come from?
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.