That's quite ambiguous. A lot of countries use dollars. Why not use the ISO currency code standard[1]? Bonus feature - you could ask for payment in XAU (gold).
I wasn't thinking a lot about different formats and properties. The idea was to get out something as simple as possible. This is just afternoon hack to see if there is any demand for it.
In all honesty, I don't completely see how "a new standard" matches with "just an afternoon hack". If all you want is measure demand, why not write a blog post "Let's make a standard for job posts!" to convince people? Worked pretty well for the markdown guys.
Standards without any effort behind them are worthless. As you can see in this thread, many people feedback the standard (which clearly needs some work), not the concept.
What is your problem with this? This is how dates are communicated in large swaths of the world (dd-mm-yyyy), including my home country. Sure, it would be better to use ISO8601 in a standard like this, but you don't see non-Americans responding with "seriously?" when an American uses "mm/dd/yyyy" (which happens a lot).
Perhaps try to be a little more open minded, and if you do decide to deliver criticism then perhaps do so in a constructive manner, instead of "seriously?".
As a non-American, seriously was close to one of my first thoughts too. Then again, I think when my fellow Canadians use that format - it's inherently ambiguous, and most likely to be understood only/mostly by Americans.
(We're more likely to use dd/mm/yy, but that's still ambiguous, and is most likely to confuse Americans.... I always use yy/mm/dd in the completely unvalidated and taken on faith belief that it will be clear. YMMV, etc.)
Right, this should have been ISO8601 to remove any ambiguity. I just think it's surprising and offensive that:
1) People consider the American format to be the one and only legitimate format, and everything else is met with resistance
2) I am getting downvoted for stating this
It wouldn't surprise me if the OP is not an American, and they simply used the format native to them. Do we really consider this enough reason to start ridiculing it?
Not only this is common all around the world but it is also "ordered" correctly. dd/mm/yyyy (smallest, middle, largest) makes a lot more sense than mm/dd/yyyy (middle, smallest, largest).
Think about the sorting use case:
Say you've got a bunch of files on your system with the date as the first part of the filename, what is more meaningful, sorting by year (2015-01-19_file), or by the date (19-01-2015_file). Clearly, sorting by year the files were created is more meaningful than sorting by the day of the month the files were created.
Edit: I completely misread your comment as saying that smallest to largest is more useful than largest to smallest, rather than the weird month-day-year thing we use in America. Completely agree an ordering by specificity is more useful, but going from least to most specificity makes it much easier to order things in a useful way.
Note the example didn't use dd/mm/yyyy. It used dd-mm-yyyy. Generally you can assume that a dash delimited date will be in European format while a slash delimited date will be American. The problems arise when British (and former British colonies) are added to the mix, because we use the European format with slashes.
How old are the people using this CV format?! For any date that would appear on in someone's work history yyyymmdd is not ambiguous, but if you're being really strict then a delimiter would fix the problem.
I think you need to stick more to existing standards.
Location: US is really big. It's a good idea to stick with ISO country codes but maybe use an optional state/province and zip code to make it more specific?
Date/time: the advantage of YYYY-MM-DD is that you can sort date strings alphabetically and they will be chronologically sorted as well. There already is a date/time standard, so why not use it? https://tools.ietf.org/html/rfc3339#section-5.6
Thinks like market, position, perks should all be coded instead of being strings. People will not write SaaS but 'Software as a Service', 'SaaS-startup', and all kinds of variations. They're US-English as well right now - that will make it even more difficult to make this an international standard. So you need find existing standards that codify these kind of things and refer to them, or make your own repository and spend effort in finding different spellings and coupling them.
The only thing that jumps out at me is that the salary field should probably include a pay period. Sometimes it can be ambiguous, especially between a fulltime engineer and parttime support personnel. If you also add support for number of weekly shifts (within a range), you can easily do salary comparisons (important).
While we're on the compensation topic, it would be nice to include sick/vacation days, recuperation etc. Pension/IRA matching should probably also be included.
I was actually looking for a JSON standard for my angularjs job board, AngJobs.
Currently it allows to POST jobs via JSON, http://angjobs.com/help, but I am considering switching to your standard in the near future when you get to 50 stars on GitHub
How about a schema for candidate profiles? If we're going to make it easy for recuiting company bots to spam me with thousands of resumes, I'd like to be able to build a robot to read them for me.
Yes each position should have "remote": true|false since even in programmers work remotely the office manager may need to be onsite. Could you make a PR please?
Oh, perfect, I needed a way for recruiters to speed up the rate at which they bombard me with mismatched job postings ("I saw your 6 years of Java/Javascript experience and found a Senior COBOL Developer position that I think is a perfect fit!").
Once a company has received a resume from a recruiter, they can't make a direct offer to the candidate for some number of months without fear of getting sued. You're not taking into account the strong financial incentive recruiters have to send out resume spam.
In PHP you cannot call $company->remote-friendly as an object. PHP treats it as a minus sign when processing code.
This is the same issue when decoding for Javascript.
No one is meant to read or write JSON themselves. It's a format for sharing data between applications (works nicely over the web, parsed easily with JS, etc). You're supposed to write it with an app. That's why it doesn't bother with things like comments - if no one should be reading or writing the JSON then there's no need for comments. The problem is that because it's easy to edit JSON in a text editor developers assume that's a good way of editing it. It isn't.
HR can't write PDFs in vi either, but that doesn't stop them using the format.
That's quite ambiguous. A lot of countries use dollars. Why not use the ISO currency code standard[1]? Bonus feature - you could ask for payment in XAU (gold).
[1] http://en.wikipedia.org/wiki/ISO_4217