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?
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.
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).
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.
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.
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.
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.
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.
[+] [-] bduerst|11 years ago|reply
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?
[+] [-] graphene|11 years ago|reply
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.
[0]: http://johnmacfarlane.net/pandoc/README.html
[+] [-] dj-wonk|11 years ago|reply
[+] [-] presspot|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] basicallydan|11 years ago|reply
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.
[+] [-] b2themax|11 years ago|reply
[+] [-] pwenzel|11 years ago|reply
For example, how does this structured approach ensure that everything fits neatly on one page?
[+] [-] jradd|11 years ago|reply
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.
[+] [-] graphene|11 years ago|reply
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.
[+] [-] eertami|11 years ago|reply
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.
[+] [-] basicallydan|11 years ago|reply
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 :)
[+] [-] graphene|11 years ago|reply
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..
[+] [-] dctoedt|11 years ago|reply
[1] http://resume.linkedinlabs.com/
[+] [-] notduncansmith|11 years ago|reply
[+] [-] erming|11 years ago|reply
The HN post can be found here: https://news.ycombinator.com/item?id=7996464
[+] [-] jimktrains2|11 years ago|reply
Otherwise its aesthetically well rendered:)
[+] [-] graphene|11 years ago|reply
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.
[+] [-] hunvreus|11 years ago|reply
[+] [-] graphene|11 years ago|reply
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.
[+] [-] relfor|11 years ago|reply
[+] [-] graphene|11 years ago|reply
In the meantime, I actually am looking for a job, see https://news.ycombinator.com/item?id=7833969 for details :-)
</shamelessplug>
[+] [-] patrickg|11 years ago|reply
[+] [-] graphene|11 years ago|reply
About your site, I used it extensively and it was a great help :-)
[+] [-] josekpaul|11 years ago|reply
[+] [-] josekpaul|11 years ago|reply
[+] [-] qthrul|11 years ago|reply
http://xmlresume.sourceforge.net/
[+] [-] dj-wonk|11 years ago|reply
[+] [-] donatj|11 years ago|reply
https://github.com/donatj/resume Build script https://github.com/donatj/Resume/blob/master/build.php
[+] [-] graphene|11 years ago|reply
Interesting, I wasn't aware of DOMPDF...
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.
[+] [-] sampl|11 years ago|reply
[+] [-] vaibhavsagar|11 years ago|reply
[+] [-] graphene|11 years ago|reply
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.
[+] [-] calebm|11 years ago|reply
[+] [-] amwelles|11 years ago|reply
[0]: https://itunes.apple.com/us/app/marked/id448925439
[+] [-] basicallydan|11 years ago|reply
[+] [-] BinaryIdiot|11 years ago|reply
[+] [-] graphene|11 years ago|reply
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 :-)
[+] [-] untog|11 years ago|reply
PDFs are fine. But, IMO, Markdown is better, because it's also demonstrating a skill that's usable in your job.
[+] [-] Argorak|11 years ago|reply
[+] [-] PhrosTT|11 years ago|reply
Then I use @media print css to make it grayscale and exactly one page if printed.
Lastly I use chrome's Print to PDF option to make a PDF version of it.
I think I could prob jam the HTML into word if I really needed a .doc but who really wants to work a place mandating that.