Show HN: JSON-based standard for job posts

https://github.com/lukasz-madon/json-job

by lukasm • 12 years ago

30 46 12 years ago

onion2k4• 12 years ago

"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

lukasm13• 12 years ago

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• 12 years ago

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.

jbob2000• 12 years ago

Haha, HR can't use this!

onion2k4• 12 years ago

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.

splitbrain• 12 years ago

"20-01-2015" - seriously?

tokenizerrr2• 12 years ago

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• 12 years ago

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

PeterWhittaker• 12 years ago

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

nsgi2• 12 years ago

Do they use it in protocols?

lukasm13• 12 years ago

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.

seagreen• 12 years ago

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.

gearhart• 12 years ago

Obligatory post to cut this argument short http://xkcd.com/1179/

benbristow• 12 years ago

Always relevant: http://xkcd.com/927/

lukasm13• 12 years ago

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

prottmann• 12 years ago

Sure? See postings above.

alexbilbie• 12 years ago

Have a look at http://schema.org/JobPosting to see if there are any other fields you could add

lukasm13• 12 years ago

Seen that. https://careers.stackoverflow.com/api/doc I could add relocation

ubertaco• 12 years ago

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

lukasm13• 12 years ago

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

giaour2• 12 years ago

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.

WhitneyLand• 12 years ago

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.

lukasm13• 12 years ago

Those probably will be optional.

steventhedev• 12 years ago

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.

lukasm13• 12 years ago

Great idea! Cloud you make a PR please?

cr3ative• 12 years ago

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

lukasm13• 12 years ago

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?

bovermyer• 12 years ago

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.

lukasm13• 12 years ago

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

tyuwan3• 12 years ago

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

lukasm13• 12 years ago

Can you explain please?

tyuwan3• 12 years ago

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

giaour2• 12 years ago

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.

lukasm13• 12 years ago

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

victorantos• 12 years ago

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

rgj• 12 years ago

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?

redmattred• 12 years ago

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

Show HN: JSON-based standard for job posts

Related Stories