I did something similar while in grad school when I was applying to jobs several years ago, except I made it so that I could customize the output.
I found myself spending so much time manipulating my resume to match each job description I was applying to, that I put all of my experiences, interests, etc. into a sqllite db. Using that, I created a UI to quickly select which items I wanted in this iteration of my resume, and then spit it out in a few different HTML formats that could be easily converted to txt or pdf. I eventually intended to do ngram matching with job description bullet points, but I got hired and moved onto other projects.
The sqllite db was overkill. Honestly I think what would have been better would have been a json format not unlike http://jsonresume.org, because it allows for more attributes, some of which could be used to group experience.
This markdown is nice because it's humanly intelligible, but what if you want to give hidden attributes to the different items - attributes which shouldn't be in the final media file?
Clojure people like EDN instead of JSON. :) When I hire contractors, I ask for an EDN formatted resume, submitted via curl to a quick web app. I validate it on the server side. People enjoyed it (at least the ones who succeeded).
It's too bad the EDN standard ain't an actual standard or proper spec. I had to rail on those people for fucking ages to get any ambiguities fixed and last I gave a damn it still:
1. Wasn't congruent with what Clojure's parser allows
2. Defined by whatever Hickey feels this year
I've worked on more than one edn parser in non-Clojure languages, it was Total Hell.
Hitching your wagon to EDN isn't advisable, there are better formats if you need them.
I don't think that "Whatever Rich Hickey feels this year" is a serious pain point. Rich isn't fickle with changes; quite the opposite. Clojure has evolved, but Rich explains himself well.
This usage scenario had occurred to me, but didn't seem like a priority in the first version. It does seem like this is where vanilla markdown would fall down, but fortunately pandoc supports header attributes in markdown source [0], and filters with which you can programmatically alter the internal representation. So potentially, this seems doable without having to use a more structured representation like jsonresume.
Am I the only person in this thread who doesn't think that the structured nature of a CV isn't necessarily super important? Having a readable, well laid-out and well-written CV can be vital in deciding whether someone is worth contacting or not.
I love putting "structured data" in formats like JSON as much as the next guy, but sometimes that approach misses the point a little bit IMO.
I think it is a lot easier to manage the content in your resume by keeping it in a structured document such as TeX or Markdown. If you manage your resume in a word document it gets messy, plus if you use markdown or TeX you can use Version Control to track or rollback the changes you've made to your resume... its very useful.
You and parent raise fair points, but I think this approach is a good compromise between the structure that you get from markdown and the aesthetics that ConTeXt is able to achieve.
To expand on your point, it's true that this approach does not automatically fit a given amount of content neatly into N pages, but I don't think there exists a system that can; you'll always have to iterate on what exactly to include if you want to have exactly N fully filled pages, regardless of your document processing workflow.
I believe there is a medium between the two. Keep your data structured, then when you're satisfied with the content, paste it into in-design and work on the layout.
They also help you focus on the content of the resume, which is really what the bottom line is anyways. I to find them impersonal and boring though, I have spent way too much time building resumes _to–order_ and have even submitted some mistakes.
Focusing on a model for your resume is kind of a helpful developmental tool itself imo.
Too bad this sort of thing will not ever catch on, or standardize. Either way it is very useful for me personally.
Not sure if you're referring to my approach or the other possible approaches mentioned in this thread, but is there anything specifically about the generated pdf that you would describe as badly laid out?
The approach in my post was specifically trying to be a more flexible format than the recently featured JSON resume, while giving ConTeXt as much freedom as possible in laying out the pdf.
Haha, no, I'm actually supporting your method. I was responding broadly to the general feeling I'm getting from the thread of "JSON is better than Markdown for a raw CV format".
I wouldn't think so, I considered a few options when I last overhauled my CV and ended up just using Word (exported as PDF).
I dunno maybe I'm lazy because I don't generate from LaTeX or Markdown or JSON or whatever but I feel that nobody reading your CV really cares as long as you present the information in a concise and clear way.
I've been playing around with this, too. Markdown -> PDF with a CSS3 stylesheet was what Iw as aiming for. I tried a few engines and none of them would preserve text, which I see as quite important for resumes. You've done a nice job though with ConTeXt.
I mostly wanted to be able to style my resume using CSS3, which is not possible with your method, which is a shame - but this is still pretty great. Nice job :)
I considered this too, and indeed I was not able to find a way to use a single stylesheet with multiple formats. However, I found that many css commands have (near) equivalents in ConTeXt, so translating the css wasn't as much work as I was fearing. I don't know how this would have worked with LaTeX, but I get the impression it wants to do more of the layout work itself..
A couple of years ago I started using LinkedIn's resume builder [1]. It takes my existing LinkedIn profile information and generates a nice-looking PDF in one of several user-selectable formats. I tweaked my profile information so that it looks decent in resume style. That satisfies 99% of my need for resumes -- and besides, most of the time anyone who asks for it has already looked at my LinkedIn profile anyway, and probably only wants a PDF as something to put in their file.
The biggest problem I see is that there is no semantic information present, making it hard for machines to digest or convert into other formats. (e.g. hResume or jsonResume)
You're right; I considered this aspect, but thought it was more important to preserve the flexibility to e.g. name sections whatever I want, or order them however I want. Ultimately I see the final document (html or pdf) as primarily intended for human, not computer consumption.
In pretty much every position where I've interviewed developers, the resumes have arrived "ready mangled" by recruiters that have cut and pasted it into word docs with their own headers and the like, so my assumption would be like yours, that it's for human consumption. Furthermore I'd assume that the chances of any semantic markup surviving past the first meeting with a recruiter is pretty close to zero.
> Ultimately I see the final document (html or pdf) as primarily intended for human, not computer consumption.
Which for a resume isn't a bad assumption. Additionally, if I choose to use something semantic to define the resume, this is a wonderful way to format it nicely:)
I agree, the two approaches are complementary, and it might even make sense to write a tool to convert from json to markdown, in order to take advantage of the formatting.
A JSON or YAML structure, like http://jsonresume.org/, may be a better approach. Markdown is great at doing regular content, not so much when it comes to dealing with structured data, which is mostly what a resume is: collections of objects for education, experience, etc.
I thought about this too, but came to the conclusion that since markdown (or, more precisely, the pandoc internal format) does offer enough structure in the form of lists, tables, headers, even footnotes etc, it makes sense to stay in markdown because it's much more human-friendly than, say, json.
I agree with you about JSON. YAML Front Matter (like in Jekyll), allows you to have a mix of both markdown (for the bio part) and structured fields (for the education, past experiences, diplomas etc). Works for websites, should work for your resume.
Happy to see the Resume is based on ConTeXt, my favorite typesetting system. The developer is a friend of mine. Loooong time ago I've started http://wiki.contextgarden.net to collect information about ConTeXt.
I think I like it better than LaTeX as well, having only used it for this project. Apart from being more convenient for specifying layout, I like the fact that it's a coherent system, compared to LaTeX's jungle of packages when you need to to anything interesting...
About your site, I used it extensively and it was a great help :-)
We are creating a service to let people create docs in json format, and share the resulting docs as interactive data docs. I feel resumes are a specialized use case for this (eg: http://www.summagram.com/Summagram/ViewSummagram/Jose%20Paul )
I just saw the jsonresume page. Very interesting. Am looking at incorporating their structure into our editor and viewer.
We have created a bridge with LinkedIn, so you can create a baseline resume which you can then enhance: http://www.summagram.com/ (click on 'create resume' button: The whole thing is in early beta, so you will be helping out the testing quite a bit by doing this).
The raw data in json format is available as well. Summagram is intended for any kind of document, so the schema is a bit generic.
Your pdf looks much nicer than what I was able to achieve going from html to pdf with wkhtmltopdf. Then again, your css stylesheet is a bit simpler than what I'm using, I wonder if that'd make a difference.
I've used this approach for the last few months and I really like it. I don't see why you need to convert to HTML and then PDF though, as pandoc is flexible enough for you to write templates for each output format. My resume (https://github.com/vaibhavsagar/resume) uses that approach.
But that's exactly what my approach does though, it improves on an earlier approach which generated pdf via html by adding a ConTeXt template which allows pandoc to generate a pdf directly, and gives the resume a similar look and feel to the html version.
Using ConTeXt instead of LaTeX has the advantage that it's nicer for setting layout properties, is more of a coherent system (in contrast to LaTeX's maze of packages), and is not specifically geared towards producing scientific documents.
I have a markdown resume as well, but I just used Marked[0] to convert it to a nicely-formatted PDF. Then again, I've never needed to submit a MS Doc file.
Markdown resumes are neat just like the LaTex and others but I feel like they're a bit gimmicky (every developer does one it seems). Maybe that's the point. Some days I feel like I'm the only one who applies a set of styles and formats to my resume current sitting in Google Docs or Word.
I get your sentiment, but I feel an important advantage of this approach is that the markdown file is much more appropriate to put in version control than a Word document would be. Also, the TeX typesetting is just that bit nicer than what you'd get from converting the .doc, but that's perhaps of secondary importance for some :-)
Thing is, as a developer, I don't have Word on my computer. So when it comes to reviewing resumes, one in Word format is going to be very difficult for me to view. I might just not bother.
PDFs are fine. But, IMO, Markdown is better, because it's also demonstrating a skill that's usable in your job.
Out of curiosity, what do you use as an alternative to Word if you do have to open something in a .doc/.docx format? Surely just saying "I don't have Word because I'm a developer" can't work in every situation?
I use Bean (for Mac, no longer supported) for reading documents. Open Office and Libre Office also work.
Honestly, I use Word for writing formal documents on the rare occasion when it happens, such as letters to the government. But not for resumes. The formatting is just too frustrating. I've been using HTML and markdown for that. www.rocketships.ca, for example. I never send .docs to anyone - .pdfs or raw text only.
I can't remember the last time I had to open anything in Word format. I did have a copy of OpenOffice installed on my last laptop - I'm sure eventually I'll get around to installing it on my current one. But I only trust OO to read Word files, I would never send someone a .docx generated by OO.
After Word/PDF/Latex/PS/HTML and XML, web-famous resumes have come so far in Flash, JSON, now Markdown. I suspect there were Java applets and iphone/android app as resumes.
In EU the Europass CV [1], or "Standard European CV" as everybody calls it, is the de-facto standard CV. It is often the compulsory format for CV for jobs in the public sector and it is also suggested by many businesses.
Hi, you might be able to take some pieces from mine at https://github.com/bamos/cv.
I use Python and Jinja templates to convert a YAML document
to Markdown/HTML and PDF and currently publish it
to my Github pages Jekyll blog at http://bamos.github.io/cv/.
I found myself spending so much time manipulating my resume to match each job description I was applying to, that I put all of my experiences, interests, etc. into a sqllite db. Using that, I created a UI to quickly select which items I wanted in this iteration of my resume, and then spit it out in a few different HTML formats that could be easily converted to txt or pdf. I eventually intended to do ngram matching with job description bullet points, but I got hired and moved onto other projects.
The sqllite db was overkill. Honestly I think what would have been better would have been a json format not unlike http://jsonresume.org, because it allows for more attributes, some of which could be used to group experience.
This markdown is nice because it's humanly intelligible, but what if you want to give hidden attributes to the different items - attributes which shouldn't be in the final media file?