jsonresume / resume-schema Goto Github PK

Is it possible to embed href tags anywhere?

A root-level optional field that holds an URL where the most recent version of the résumé can be found.

Typical use case: my résumé can be found on a job search website, on an alumni network and in a common database, but the official and up-to-date version should be downloaded from my own website at https://nicollet.net/resume.json.

Field name suggestions: url, canonicalUrl, officialUrl or even latest.

This might be redundant with hobbies? If that is the case I'd argue that hobbies should be renamed to projects. It makes a stronger impression.

Proposed projects section would be a place to add work done outside the "work" (paid) context. For example, assuming JSON Resume isn't something being made for an employer, it doesn't have a clear place in the current format.

Potential properties:
projectName
startDate
endDate
url
description

Add a section for patents granted, similar to the awards section.

patents: [{
    patentNum: string,
    issueDate: string,
    title: string,
    abstract: string,
}], 

Are endDates exclusive or inclusive?

I suppose you mean inclusive, but it might be worth being explicit somewhere.

It would be great to see a section dedicated to Volunteering experience, something that I don't think quite fits in with either hobbies or work.

@tmaier

like DOI, ISBN or another number.

name: string
publisher: string
releaseDate: string
website: string
identifiers:

• type: doi
  identifier: string // e.g.10.1000/182
• type: isbn
  identifier: string // e.g. 978-3-16-148410-0

Anyone wanting to discuss issues in further details should join the chat

ATM, to represent a 5-year stint at a company during which you did many different jobs, you'd need multiple jobs entries. perhaps it would be best to have positions be an array of objects?

Ever since I worked for a recruitment startup, I have pushed for standardization of resumes but for this to catch on, I think job descriptions need to also be standardized. And if both are standardized, you would want to make some changes according to the theory of Person-Job fit.

In Industrial-Organizational Psychology we determine how a person fits with a job by first determining the KSAOs, or Knowledge, Skills, Abilities and Other Characteristics (e.g. personality), needed to complete all tasks of the job. Then we design tests, interviews, and other selection tools to assess applicants on their level of each KSAO. Thus, for each job description and resume, you would be able to best predict fit, if the JD and resume each had matching KSAOs.

P-J fit is only one aspect of selecting a candidate. You could also try to match an applicant to a job based on shared values with an organization (Person-Organization fit), how their skills complement their immediate working group (Person-Group fit), or how their work style and norms align with their immediate supervisor (Person-Supervisor fit).

Takeaways:

1. Create a complementary JSON Job Description
2. Include fields for Knowledge, Abilities and Other Characteristics in addition to Skills
3. Include a field for values.

work and personal email/phone should likely be an array

@inadarei

In any message format design it's a good idea to make things that can change be data elements, rather than structural elements. Changing structural elements breaks things, data elements provide evolvability.

Phone and e-mail fields have a lot of variance. People have different types of phones, emails and they don't necessarily limit them to "work" and "personal". Making such assumptions is wrong.

Instead following is what you could do.

This:

email: [
{"type": "work", "value" : string}, // e.g. [email protected]
{"type": "personal", "value" : string} // [email protected]
],

is more evolvable than this:

email: {
work: string, // e.g. [email protected]
personal: string // [email protected]
}

the same is true for the phone field.

The education section really doesn't lend itself well for things like MOOCs (Coursera, Udacitiy etc.), because there's no degree involved, and only one course etc.
Maybe there should be separate section for courses like that? Just like on LinkedIn :)

At least in Germany, it's standard practice to include a short section of personnel master data at the top of the CV.

Example:

Name = John Doe
Birth = 6th December 1980 in Berlin
Citizenship = German
Family status = married
Children = two (6 and 12 years)

Although that might not be common in other countries, could this be added as an optional section?

Example:

master_data: {
    name: string,
    birth: {
        date: integer,
        place: string
    },
    citizenship: string,
    family_status: string,
    children: [{
        gender: string,
        birth_date: int
    }]
}

From @akhyrul

Hi, I don't know if it's the right place to comment on JSON resume standards.
I took a quick glance on the JSON schema in the main website (http://jsonresume.org) and found a minor issue. Should the work and education fields written in their plural form (i.e. works and educations) just as any other array fields (e.g. skills, hobbies, references) conventions?

Let me know what do you think of it :)

every work should have an optional lat, lng. this would give me a map of areas worked, and also ties in experience duration with locations which can help companies offer jobs by location relevance and comfort factor with the location.

This may have been suggested already, but any thoughts on using Schema.org vocabulary?

http://schema.org/docs/full.html

There should be a page comparing this schema with the information requirements of other resume-distribution services (e.g. linkedin, facebook, seek.com, monster.com, careerone, etc), together with code samples to maintain resumes across multiple sites.

it would also be good to maintain compatibility with hResume ( http://microformats.org/wiki/hresume ), or to move the project under that banner.

As a non-American, I find it strange why there would be two ways to specify a region when neither of them applies to the Dutch "province" or the Swedish "landskap" (or "län") or "oblast".

Can't you just remove "state" and add this to the description: "Americans put state in the region field. Others may put region or province or whatever seems most likely for their country there."

I notice that you have both "firstName" and "lastName" as entries in the scehma. May I propose that this be amended to just a single name? This is in the spirit of "Falsehoods Programmers Believe about names".

In this case, the assumption that people have a first name and a last name is probably not suitable for resumes. If the goal is to have the ability to output a resume which uses their full name, and also only their first name, then perhaps a different solution is required. For example, a "name" (e.g. Peter Serwylo) and "preferredName" (e.g. Peter or Pete).

The final case which I think people may want to have separate first/last names would be so that resumes can be output with the surname first (e.g. Serwylo, Peter). I'm not quite sure of how to achieve this with only a single name unfortunately.

At any rate, the points in the article linked above are worthwhile considering, as are many of the comments people have posted to that article. Cheers.

References has name and reference. You'll want to know when that reference was created. The age of the reference matters.

Also, an optional phone number and/or email address of the referee would be nice, so we can confirm that the reference is legit.

For location, the spec says to give "state" or "region". Which is good, not countries hhave states. However the example of a non-state region is Queensland.... which is a state of Australia... Perhaps a different example

"All collections are arrays except for websites. Does not look very consistent.

Edit: Also websites are under bio, also seems not very logical." - @zepplock jsonresume/resume-cli#5

Moved this issue from the resume-cli tool, I agree, this part needs some rework.

We eventually want people to edit their resume's using a UI on the registry website etc

But we will run into problems with keeping resume.json's in sync.

e.g. If you edit it online and then publish from your local copy on your box you will override the changes you did on the registry.

We were thinking of adding a revision property which auto increments whenever you publish.

I wonder if firstName/lastName should simply be changed to 'name'?

first/last is a bit restrictive (middle names etc) and not culturally universal.

w3.org has a great article on this:

"If designing a form or database that will accept names from people with a variety of backgrounds, you should ask yourself whether you really need to have separate fields for given name and family name."

http://www.w3.org/International/questions/qa-personal-names

As per HN comment

In the education section, I'd like to see an option for GPA or degree class. Be aware that some countries do not provide a GPA (for example, the UK has these classes: 1st, 2:1, 2:2, 3rd).

As a speaker on local conferences I want to describe my experience in resume. Something like:

"talks": [{
  "conference": string,
  "date": string,
  "title": string,
  "link": string // e.g. link to video
}]

Example:

"talks": [{
  "conference": "JSConf EU 2013",
  "date": "2013-xx-xx",
  "title": "Stop Breaking the Web",
  "link": "https://www.youtube.com/watch?v=OSEXpsVcTxI"
}]

I think this section can be useful.

Someone should be able to specify what professional presentations they have done.

If there are publicly available links (apart from Blog) like Tableau Public, etc., having a placeholder for that will help. We can call this as LiveLinks, which can be used by the employers to click and see the kind of work that have been done by the job seeker.

This may be too "tech specific" for a general standard, but any resume I've written (and most I've reviewed) have included a section for listing out the tools / technologies used in a previous position.

This is helpful for passing resume filters, and gives the reviewer an at glance "have they used X random tool professionally" without eating up valuable page space.

Example:

Tools Used: GitHub, Zend Framework 2, Stripe, Bootstrap 3, PHPUnit

Hi all,

I love this concept, thank you!!! For this schema to work in a South African context, there are a few things missing. South African employment requires street addresses as well as (and this might freak you out): Race.

This is because we are still in the midst of Black Economic Empowerment, and Employment Equity post apartheid.

If you don't mind, I'd like to add these fields as optional parts to the schema.

Let me know, and I'll issue a PR.

The vision for this project is clear, and I find it incredibly exciting.

But I could see a much bigger impact and lots of tools emerging if the schema offered the option to extend the records beyond a CV to become a full job application.

I see that the other parts of a full job application, notably cover letters, don't really fit in, as they are always-changing.

But if you consider the practical use, what people could do with the schema and what tools could develop around this project (e.g. GUIs for creating job applications from scratch), the schema requires support for the remaining parts of a job application.

You don't have to use those parts, of course. But if they don't become part of the schema, all the tools being developed will lack support for those parts as well.

The world has a great richness of cultures, countries, industries and people. And if you don't support a variety of needs, the schema is never going to be universal.

Just imagine the following additions:

cover_letter {
    job_title: string, // e.g. caretaker
    date_line: string, // e.g. London, 01/01/2001
    salutation: string, // e.g. Dear Sir/Madam
    text: string, // e.g. I would like to apply to ...
    company_name: string, // e.g. Example Inc.
    company_contact: string, // e.g. Jane Doe
    company_street: string, // e.g. 123 Example Street
    company_city: string // e.g. Example City 54321
},
location: {
    street: string // e.g. 123 Example Street
},
references: [{
    file_path: string // e.g. http://www.example.com/images/scanned_reference.jpg
}]

The schema would instantly support cover letters as an optional feature as well as scanned references that could be displayed full-page.

We should leave the specific arrangement and implementation up to users and themes, but we should provide support for features that are truly universal.

Considering the share of users who create CV and cover letter in combination every single time, I can see huge numbers go off the boil when they see that they're not able to create both parts in a consistent design.

Take it from me, unless you have a handle/id (ex FBid)/standardurl setup its going to lead to issues.

It appears that the links that you point to on the website for loading the 2 different themes is just loading the same thing.

Both
http://registry.jsonresume.org/thomasdavis?theme=modern
http://registry.jsonresume.org/thomasdavis?theme=traditional

produce the same html output and structure as far as I can see.

As I understand it, it is required to specify either a region or a state. In most countries this information is totally useless.

None should be required.

@tracker1
Given that many have worked in contractor roles, where you are working at/for one company (Microsoft), but employed by another (Volt), it would be nice to see this as part of the specification... I think it's a big oversight in most resume systems.

@tmaier

Heroku suggests to downcase JSON attributes: https://github.com/interagent/http-api-design#downcase-paths-and-attributes

country_code would be better than countryCode

In my opinion, every work should have a project sub array, detailing:

1. Duration
2. Skills
3. Responsibilities
4. Description

As much as it said that physical appearances shouldn't influence a resume, I believe the choice should be left to the user whether or not he wants to use a photo in his resume.

For people living in countries with multiple official languages (i.e. Canada has english and french), what is the recommandation?

It would be nice to be able to repeat sections with a identifier, i.e. FR_CA, EN_CA, etc.. So I would be able to generate PDFs with multiple languages.

List notable ...
or
List any notable ...

Cheers,
Walter

Probably best done by making contactMethods be an array of objects that are of type email/phone/twitter/etc. This also makes for better future extensibility (maybe skype or whatsapp become the big deal.

So that resumes would easily be filtered.

Hey guys,

For those of you helping out with debating the specification we would like to start building an official standards committee and also make publicly known those who have contributed minor recommendations.

We currently do not have a release system for specifications, there are quite a few moving parts which need to be versioned and this issue will be to document them all and any pitfalls.

resume.json will need to contain a version of the draft, if left out, validation should run against the latest.

Maybe a top level version property

{
  "version": "0.0.1",
  "bio": ...
}

Employers would like to be able to contact and do due diligence on references sometimes, but of course a candidate might want to make referrals available upon request etc.

Where I live, it is common to have your resume in two languages. It would be nice if there was support for that.

Language skills are usually listed independently of normal skills. Also, they follow specialized scales, usually the CEFR or the ILR:

http://en.wikipedia.org/wiki/Common_European_Framework_of_Reference_for_Languages
http://en.wikipedia.org/wiki/Interagency_Language_Roundtable_scale

most resume has a tagline/objective, since bio could serve a different purpose?