Show HN: JSON-based standard for job posts(github.com)
github.com
Show HN: JSON-based standard for job posts
https://github.com/lukasz-madon/json-job
47 comments
Yes. That's a great idea. XBT for bitcoin.
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.
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.
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.
I disagree. Blogpost could be made just out of vanity or need to whine and yes-men can get exacted for the wrong reasons.
MVP shows that I'm at least competent to do it and have the will to put some hours to improve it.
Also, I don't have a popular blog.
MVP shows that I'm at least competent to do it and have the will to put some hours to improve it.
Also, I don't have a popular blog.
"20-01-2015" - seriously?
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?".
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.)
(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?
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).
It really doesn't though.
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.
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.
The only truly unambiguous format is yyyymmdd.
The only truly unambiguous format is yyyymmdd.
Not sure how yyyymmdd is unambiguous. 10111012 do you mean 10th Nov 1012 or 1011 Oct 12th
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.
yyyy/mm/dd is ordered even more correctly. With dd/mm/yyyy the most significant digit is the 5th of eight and the least is the 2nd.
Do they use it in protocols?
JSON Schema already (optionally) supports datetimes, they definitely shouldn't make up their own way: http://json-schema.org/latest/json-schema-validation.html#an...
I love the goal of the project though.
I love the goal of the project though.
This is just afternoon hack to see if there is any demand for it.
It should be ISO, but before I allocate time to work on it I'd like to see if there any demand.
It should be ISO, but before I allocate time to work on it I'd like to see if there any demand.
Obligatory post to cut this argument short http://xkcd.com/1179/
One problem is that most postings will not advertise equity splits and most of the time not even a salary range.
One off the cuff solution would be to add a seniority enumeration like seniority: "junior", "senior", "super duper".
Another solution would be to move the sensitive information to another record type or somehow mark it as not public.
One off the cuff solution would be to add a seniority enumeration like seniority: "junior", "senior", "super duper".
Another solution would be to move the sensitive information to another record type or somehow mark it as not public.
Those probably will be optional.
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.
You could classify businesses using NAICS (http://en.wikipedia.org/wiki/North_American_Industry_Classif...) and SOC codes to classify job titles. For instance a backend engineer has SOC code 151133 (http://www.bls.gov/soc/2010/soc151133.htm). These are still US-specific standards, but it's better than inventing your own, or none at all.
Type: full-time. Maybe make this hrs/week?
For descriptions maybe make it an associative array with ISO language codes as a key, and the description in that language as a value?
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.
You could classify businesses using NAICS (http://en.wikipedia.org/wiki/North_American_Industry_Classif...) and SOC codes to classify job titles. For instance a backend engineer has SOC code 151133 (http://www.bls.gov/soc/2010/soc151133.htm). These are still US-specific standards, but it's better than inventing your own, or none at all.
Type: full-time. Maybe make this hrs/week?
For descriptions maybe make it an associative array with ISO language codes as a key, and the description in that language as a value?
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.
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.
Great idea! Cloud you make a PR please?
Have a look at http://schema.org/JobPosting to see if there are any other fields you could add
Seen that. https://careers.stackoverflow.com/api/doc I could add relocation
Indeed & SimplyHired's format are the defacto right now for much of the HRtech/jobboard world:
http://www.indeed.com/intl/en/xmlinfo.html
http://www.simplyhired.com/a/add-jobs/example-xml
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
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.
> The open source initiative to create a JSON-based standard for job posts. Inspired by jsonresume.org
I approve of this. It needs some polishing, as others have mentioned, but it looks like a worthwhile format to support.
The trick, though, is in getting people to support it.
The trick, though, is in getting people to support it.
I sent a link to a friend that works for lever.co Maybe companies that work in this space would be more interested.
Surely "remote-friendly" should be per-role not per-company? Some roles are much more remotable than others.
remote-friendly means that company has a remote DNA. This project was partially inspired by https://github.com/lukasz-madon/awesome-remote-job
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?
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!").
I don't understand your point. It's quite the opposite
- You can automate posting to multiple job boards
- Move easily the data between systems
- Have dead simple filter for incompetent people e.g. https://github.com/lukasz-madon/hackers-job-apply
- No more scrapers
- Build data aggregators to find a perfect fit
et cettera
- You can automate posting to multiple job boards
- Move easily the data between systems
- Have dead simple filter for incompetent people e.g. https://github.com/lukasz-madon/hackers-job-apply
- No more scrapers
- Build data aggregators to find a perfect fit
et cettera
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.
The hyphen column is not PHP friendly when decoding to object.
Can you explain please?
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.
I would recommend using underscore
I would recommend using underscore
You can in PHP [1] and JavaScript [2] - though neither is pretty, so I'd endorse this suggestion.
[1] http://stackoverflow.com/questions/2925044/hyphens-in-keys-o... [2] http://stackoverflow.com/questions/7122609/how-do-i-referenc...
[1] http://stackoverflow.com/questions/2925044/hyphens-in-keys-o... [2] http://stackoverflow.com/questions/7122609/how-do-i-referenc...
Yup, There is more than one way to handle it but it's not developer-friendly.
Always relevant:
http://xkcd.com/927/
Haha, HR can't use this!
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.
HR can't write PDFs in vi either, but that doesn't stop them using the format.
[deleted]
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