jsonresume/resume-schema

Add section to Education for GPA(international)

thomasdavis opened this issue · 30 comments

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).

+1

I disagree, but that's more from an idealistic standpoint :) GPA tells you exactly nothing about a candidate, at least nothing more than can already be gleaned from the "area", "institution" and "studyType". I'm happy that - at least in the tech industry - we're moving away from the need to quantify these things. For instance, Google doesn't care about your GPA.
In short: I don't see the need to support adding your GPA. You don't put your GPA on LinkedIn either, do you? :)

For better or worse, GPA is still very common on resumes - especially for recent grads who don't have much or any previous work experience. When in doubt, the schema should be more inclusive than exclusive, as the resume generators/themes can be configured to ignore information in the schema. If the schema errors on the exclusive side, I suspect we will see themes that expect custom data in the json files, which isn't going to help proliferate the standard.

I agree that we should probably include it when in doubt, as long as it doesn't create a lot of complexity (which I don't think it will).

For better or worse, GPA is still very common on resumes - especially for recent grads who don't have much or any previous work experience.

I must say that I'm surprised by this. I've seen lots and lots of resumes, also from recent grads, and I never say something like a GPA on there. I guess it's an American thing then, also because in most of Europe, GPA doesn't even exist.

Yes it's still a big deal here in the States - not so much for advanced/graduate degrees, but certainly as an undergraduate.

+1 for including it then.

Sidenote: work to get rid of that arcane metric for job candidates, even if they're undergraduates ;)

It's not that much to put in and lots of people do use it.

+1

Though it would be nice to know of other countries scoring systems.

osg commented

+1 for optional

Issue marked as PR needed,

gpa will be added to education objects as type string

PR for schema.json here: #97

Is the resume.json a real-world example where we can't add values as we don't know them? Or is it an exemplary "John Doe" resume (which it should be)?

And what's the process for the schema.json.html? Maybe a CONTRIBUTING.md or something like this should be added.

resume.json is an example resume that is exported in the resume-schema node module, so other NPM modules can depend on resume-schema and get a fully filled out example to play with.

Ignore that html part for now, it's used to generate the docs on homepage, but isn't very elegant.

I've added this change log in README. Gw guys

Shouldn't the example resume be re-exported for each change in schema.json?

+1, my university uses classes instead of gpa.

What about international grading systems?
In Germany, for example, 1 is the best grade (sehr gut / very good) and 6 is the worst (ungenügend / not sufficient, failed).

How should one determine, wether grades are assigned in ascending or descending order?
In Germany 1.2/6.0 would be considered very good, while in the U.S. this could be perceived as very bad.

Adding another comment - in the UK we don't use GPA at any level. GCSE and A-Levels are letter graded (A*/A/B/C, etc). Degrees are first/second/third class. I'd use a freeform "grade" field

GPA is a string. You can put whatever you want in there. Making this internationalized in some structured manner opens it up to boatloads of unnecessary complexity. A couple of reasons to leave it as is:

  • The decision has been made. We can keep discussing it, but then there will never be a first official version of this spec. We can always come back to it at a (much) later time.
  • As far as I know, there aren't actually many countries where employers want to know your GPA. It only makes sense to add it for countries where it is required for getting a job. If you add it for that reason, you should stick to the standards of the country where you're applying.
  • You could also assume that any "score" that is put into this field, should be interpreted based on the country where this person had his/her education.

@dandydev Agree. What else can we do other than making it a free-form string? That should suit all purposes. Everything else will introduce much new complexity.

@dandydev I agree with Free-form string. But why can't we give it a Name that works for any country.

GPA is used exclusively in the USA, so people outside the USA often find themselves confused whether they should use it or ignore it.

But giving it a name which makes sense in each system such as Grade or Results or something akin, that adds more flexibility and reduces chance of confusion.

The question then becomes, what semantically makes sense as a universal name for the field?

In the UK an much of the EU, if you're a graduate and it's your first real role, they do tend to prefer to know your grade on the Resume. But for anyone after that point the field becomes useless.

We are working on a solution, which doesn't rely on people interpreting the grade. Grades have different meaning in various regions and a free form field just pushes the problem to the writer and the reader to associate the same.

It's been almost 3 years since my last comment, and I agree with the recent comments that GPA is too specific a name for that field. Something like "Grade" would be better.

Regarding the value of the field, I'm very curious about the solution which doesn't rely on people interpreting the grade. Why is such a solution desirable? What is wrong with people interpreting this thing?

guess if you make it not requiring interpret you could have it possible for non-humans to auto-fill it more easily.

It enables easier cross region usage, makes the standard more generic and additionally makes it possible to be used by non-humans.

Current idea is to have a percentage scale to store the grade and also call the field "grade" or "score". The interpretation is then moved to a utility function, which makes it easier to provide region specific inputs and outputs and translates them into the generic standard.
A really bare mockup from something similar in the works for skills:
skills
(sidenote for skills: beginner will now start at 10%)
For score and grades it might show the region specific values on the scale or something like that. Suggestions are welcome.

Well, in the EU, self-rating of skills on a scale is seen as conceited and pointless, as we tend to go for descriptive instead,

As I'm also from the EU I understand this concern. The reasoning:

  • machine readable scale
  • easy to transform into region specific things
  • easily used in addition to other forms such as a description (see vim example)
  • workable to input without region specific notions
  • no focus on regional specifics within the standard (cause of cross region work, remote work)

Happy to keep discussing.
We definitely discussed in length the european focus on achievement and not self judgement. That's one of the reasons, why we added the subsection "highlights" to basically showcase what you did instead of just adding less valuable (depends on who you ask) self judged information.

I know I haven't been involved with the project for a long time, so maybe I'm not in the right place to deliver critiques. But I think what you're proposing @stp-ip, with interpreting grades in utility functions, per region etc., is waaay over-engineered.

This works for json-resume's own utilities/applications, but what about someone writing an application that can import/use resumes described in json-resume, and they write the application in a language other than Javascript? Now they have to rewrite that logic, potentially leading to differences in interpretation...

As far as I'm concerned, there should be little to no interpretation of fields and their datatypes by parsers of the json-resume standard. The notable exception being datetimes, because JSON doesn't natively support those (they'd be expressed as strings).

Thanks for the critique. How the utility functions actually work is still flexible. Could be that they write to an additional data section or so.

Adding all regional variances seems like quite a lot of bloat especially considering the various jobs wanting special cases too. We would move from a basic standard, which is extensible to something trying to do everything, but nothing at all.

I appreciate you coming back and contributing with your time.

No problem! I still hope to see this project succeed and getting a lot of adoption :)

Regarding regional variances: I'm still of mind that we shouldn't deal with those at all. I'd say it is enough to have a field named grade with a string as value. Leave to users of the standard to do something with it or not. Especially in light of what I said 3 years ago: although we want to support adding grades to your eduction, we don't want to encourage that as a widely used selection criterium. But that's my opinion ;)

Will definitely take that all into consideration. Hope it's ok to ping you, when we have a first draft of our overhaul.

Sure! Looking forward to it!