Live data from Hacker News

JSON Resume – 5th Birthday and New Features

jsonresume.org

11–20 of 58 posts

Re: JSON Resume – 5th Birthday and New Features

#11
post #10

How much traction is this getting in job-tech startups? For instance, LinkedIn, Indeed, etc., as well as applicant tracking systems, and so forth.

> LinkedIn, Indeed, etc., At this level, they won't care for an open format as they can just ask you to reenter all the info in their own form. They assume if you are effectively looking for a job a 10~30 min data entry for each of these sites won't deter you. Or worse, you'll get tired of entering your data again and again, and won't go to their smaller competitors even if they make more efforts to accommodate you.…

This is true in our experience. We had visions of exporting Linked in profiles to the schema but about a year after launch LinkedIn completely disable API access to user profiles making it virtually impossibly.

A developer built a bookmarklet that does it thought -> https://joshuatz.com/projects/web-stuff/linkedin-profile-to-...

Works surprisingly well.

Re: JSON Resume – 5th Birthday and New Features

#12
Pro tip, just creating your own schema. Tailor it to your theme.

Here is my resume (as YAML): https://github.com/pauldotknopf/resume/blob/staging/resume.y...

This file is consumed and used in a very small ad-hoc project, specifically for my format: https://github.com/pauldotknopf/resume/blob/staging/statik-r...

Here is the final result: https://resume.pknopf.com/

Easy maintenance. Maximum flexibility. Low tooling.

Re: JSON Resume – 5th Birthday and New Features

#13
post #7

Instead of going with an ad-hoc schema, I wish JSON Resume built on top of data structures standardized by Schema.org. They cover most of the concepts required— https://schema.org/Person , https://schema.org/skills , https://pending.schema.org/knowsAbout , the list goes on. For concepts not covered by Schema.org (I spotted only one, “interests”) the project could implement custom extensions until they are adopted by…

I personally don't disagree, we've always thought it best to leverage other peoples work first.

Though one of the largest discussions we had on the specification was the definition of what a name was -> https://github.com/jsonresume/resume-schema/issues/4

After everyone's input, we decided to just opt for one field `name` because simply first/last/family name does not work across cultures.

When we looked at schema.orgs definition of Person, they went down the avenue of trying to split the name up which still wouldn't fit all use cases.

https://schema.org/Person

Re: JSON Resume – 5th Birthday and New Features

#15
post #7

Instead of going with an ad-hoc schema, I wish JSON Resume built on top of data structures standardized by Schema.org. They cover most of the concepts required— https://schema.org/Person , https://schema.org/skills , https://pending.schema.org/knowsAbout , the list goes on. For concepts not covered by Schema.org (I spotted only one, “interests”) the project could implement custom extensions until they are adopted by…

I personally don't disagree, we've always thought it best to leverage other peoples work first. Though one of the largest discussions we had on the specification was the definition of what a name was -> https://github.com/jsonresume/resume-schema/issues/4 After everyone's input, we decided to just opt for one field `name` because simply first/last/family name does not work across cultures. When we looked at schema.or…

> After everyone's input, we decided to just opt for one field `name` because simply first/last/family name does not work across cultures.

Thank you so much for this! Me and family members struggle filling forms because of this on a regular basis.

Another pet peeve of mine are address fields. Why not just one field? People are smart enough to write down their address. Not everyone has a zip code or a street number, or streets for that matter.

Re: JSON Resume – 5th Birthday and New Features

#16
So, I am working on a "better resume" product for developers: https://fizbuz.com

We plan on shipping API support so that developers can build better experiences on top of the data (alternate rendering engines, import/export, etc).

I'd love to see about supporting export to JSON Resume. Is there a list of ecosystem tools that speak this format?

Re: JSON Resume – 5th Birthday and New Features

#18
post #16

So, I am working on a "better resume" product for developers: https://fizbuz.com We plan on shipping API support so that developers can build better experiences on top of the data (alternate rendering engines, import/export, etc). I'd love to see about supporting export to JSON Resume. Is there a list of ecosystem tools that speak this format?

We haven't done a good job of showing casing community tooling. It is on our high priority list. That being said, you can scroll through https://github.com/search?o=desc&q=jsonresume&s=updated&type... to get an idea of what is out there.

Re: JSON Resume – 5th Birthday and New Features

#19
post #7

Instead of going with an ad-hoc schema, I wish JSON Resume built on top of data structures standardized by Schema.org. They cover most of the concepts required— https://schema.org/Person , https://schema.org/skills , https://pending.schema.org/knowsAbout , the list goes on. For concepts not covered by Schema.org (I spotted only one, “interests”) the project could implement custom extensions until they are adopted by…

I personally don't disagree, we've always thought it best to leverage other peoples work first. Though one of the largest discussions we had on the specification was the definition of what a name was -> https://github.com/jsonresume/resume-schema/issues/4 After everyone's input, we decided to just opt for one field `name` because simply first/last/family name does not work across cultures. When we looked at schema.or…

Actually, Person does inherit a generic “name” property from its parent (Thing). You could support a subset of the spec (“name” but not “firstName”). It’d be very cool if I could have a single structured data representation that could be displayed in a neat resume format while being consumable by others (say, Google[0]).

PS. Agreed on your name handling philosophy, I use a single “name” property wherever requirements allow.

[0] https://developers.google.com/search/docs/guides/intro-struc...

Post reply on HN