

Show HN: JSON-based standard for job posts - lukasm
https://github.com/lukasz-madon/json-job

======
onion2k
_" currency": "$"_

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](http://en.wikipedia.org/wiki/ISO_4217)

~~~
lukasm
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.

~~~
skrebbel
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.

~~~
lukasm
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.

------
splitbrain
"20-01-2015" \- seriously?

~~~
tokenizerrr
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?".

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

~~~
onion2k
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.

~~~
lukasm
Not sure how yyyymmdd is unambiguous. 10111012 do you mean 10th Nov 1012 or
1011 Oct 12th

~~~
onion2k
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.

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

~~~
lukasm
Those probably will be optional.

------
rgj
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](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...](http://en.wikipedia.org/wiki/North_American_Industry_Classification_System))
and SOC codes to classify job titles. For instance a backend engineer has SOC
code 151133
([http://www.bls.gov/soc/2010/soc151133.htm](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?

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

~~~
lukasm
Great idea! Cloud you make a PR please?

------
alexbilbie
Have a look at [http://schema.org/JobPosting](http://schema.org/JobPosting) to
see if there are any other fields you could add

~~~
lukasm
Seen that.
[https://careers.stackoverflow.com/api/doc](https://careers.stackoverflow.com/api/doc)
I could add relocation

------
redmattred
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.indeed.com/intl/en/xmlinfo.html)
[http://www.simplyhired.com/a/add-jobs/example-
xml](http://www.simplyhired.com/a/add-jobs/example-xml)

------
victorantos
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](http://angjobs.com/help), but I am considering
switching to your standard in the near future when you get to 50 stars on
GitHub

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

~~~
lukasm
> The open source initiative to create a JSON-based standard for job posts.
> Inspired by jsonresume.org

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

~~~
lukasm
I sent a link to a friend that works for lever.co Maybe companies that work in
this space would be more interested.

------
cr3ative
Surely "remote-friendly" should be per-role not per-company? Some roles are
much more remotable than others.

~~~
lukasm
remote-friendly means that company has a remote DNA. This project was
partially inspired by [https://github.com/lukasz-madon/awesome-remote-
job](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?

------
ubertaco
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!").

~~~
lukasm
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](https://github.com/lukasz-
madon/hackers-job-apply)

\- No more scrapers

\- Build data aggregators to find a perfect fit

et cettera

~~~
giaour
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.

------
tyuwan
The hyphen column is not PHP friendly when decoding to object.

~~~
lukasm
Can you explain please?

~~~
tyuwan
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

~~~
jtruk
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...](http://stackoverflow.com/questions/2925044/hyphens-in-keys-of-
object) [2] [http://stackoverflow.com/questions/7122609/how-do-i-
referenc...](http://stackoverflow.com/questions/7122609/how-do-i-reference-a-
javascript-object-property-with-a-hyphen-in-it)

~~~
tyuwan
Yup, There is more than one way to handle it but it's not developer-friendly.

------
benbristow
Always relevant: [http://xkcd.com/927/](http://xkcd.com/927/)

~~~
lukasm
I totally agree with xkcd, but the problem is there is nothing like that
anywhere!

~~~
prottmann
Sure? See postings above.

------
jbob2000
Haha, HR can't use this!

~~~
onion2k
_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.

