Hacker News new | past | comments | ask | show | jobs | submit login
Proposed Who Is Hiring Spec (github.com/perspectivezoom)
106 points by perspectivezoom on May 31, 2015 | hide | past | favorite | 16 comments

This is not going to work unless it is enforced by software running on the HN servers. Many of the hiring posts are posted by non-hackers who don't give a flying roomba about specs and correct formatting. The ideal format would be something generated by a set of dropdowns and textareas, but then again, would it still be HN?

For job-seeking engineers, it would be interesting to then write another script that filters for only the posts in the correct formatting. This at least gives some level of comfort that you're talking to hackers and not sales/business people.

Also, prospective employees don't both reading the details either, and just mass apply to jobs, regardless of whether or not the employer asks for local candidates only, etc.

I really like this, but salaries should definitely be considered something that could (optionally) be added as well.

I guess this is the HN way of turning a simple proposal by dang (for feedback) into an engineering problem where we try to solve:


The optimal method of describing a job post where the utility of most users/readers is, at least, mostly satisfied



I think salaries should be required-- if not by rule, then by convention.

Companies have been asking candidates to give their salary up front ("expectations" or "history") without ever justifying it when it's obviously not in our best interest to do so...yet they do already have a budget for these positions, so let us decide if we are in the range or not. (Rather than applying for jobs which will never offer a salary commensurate with our experience because we read the demand for high end skills and "salary commensurate with experience"-- and don't realize it's someone trying to score a deal, and not really offering a market salary.)

"Onsite" and "remote" are not sufficient, unfortunately. Remote should be obvious, but a lot of companies say "remote" when they mean "you can work at home a couple days a week"... rather than really remote. So we need a new word for "work from home ok" thats distinct from "remote" (Which means "work from another state ok" I don't mind employees requiring you to be in the same country, but in the same state is a problem.)

Isn't this basic just a job listing micro format? http://microformats.org/wiki/job-listing

This spec isn't very human friendly. As a human this bothers me.

Their explanation of a line break doesn't really explain why JSON or something wouldn't work. Strip whitespace from input and it's basically the same.

I think breaking a bit from the current de-facto format would be better. Consider the example:


Acme Products | Test Engineer | Las Vegas, NV; Austin, TX | Onsite; Remote | Full-Time; Part-Time | Visa (H1B) | Tunnel Theory; Kinematics

Engineer needed to test prototype products. Must be able to lift and carry anvils. metafriendly


The only real problem I've had with existing listings, is that people tend to list both "remote" and "no-remote" -- making search hard.

I propose moving those "tags" to "hash-tags", and just list them at the bottom of the ad:


Acme Products | Test Engineer | Las Vegas, NV; Austin, TX

Engineer needed to test prototype products. Must be able to lift and carry anvils. metafriendly

#on-site #full-time #part-Time


Note that the two are different; I don't see how you could work remotely testing anvil-lifting... ;-)

At any rate, if we're talking about a new "spec", I'd say:

* Apart from position, and location, as little as possible on the first line.

* Replace the "text"-tags with "hash"-tags - #remote is easy to search for with text-search, and won't match #no-remote, No-remote -- and doesn't require regexp magic to match word-boundaries etc (which few (no?) browsers support anyway).

* Put the tags at the bottom -- they're really for searching (and machine parsing), with the amount of listings we are getting now -- no-one is reading just your ad, they're reading a stream of ads.

* Don't go overboard with "hash"-tags. I'm not all that interested in seeing: mulitple-line lists of #python #ruby #haskell #c++ #dev-ops (...)

Now, if we really want to over-engineer this thing, why not draw some inspiration from the Dewy decimal system? So 001-234 could be 001:devops 2:python and bash 3:unix-like-and-windows-nt 4:remote-or-onsite ... ;-)

Is there a way to be more clear about whether the company will apply for an H1B for a candidate, as opposed to sponsoring an existing one? I have a lot of friends who talk to companies that end up saying, "we only sponsor existing visas."

It is really, really hard to apply for an H1B for a candidate unless they just graduated from college and are on OPT. If they are on OPT they basically have 2 chances to apply for an H1B. If you don't, then the employer would have to apply on your behalf on April 1, with a coin-flip probability of getting one, and even if they got one the employee couldn't start work until October 1. That makes anything except an H1B transfer prohibitively risky and inconvenient.

The real answer, as many have tried to implement, is another site/tool entirely. One that allows filtering, notifications etc.

Pretty easy to build, not so easy to get community engagement unless the HN folks endorse it officially as an alternative.

Another site probably won't solve the underlying problem that Who is Hiring addresses - the problem of non-YC companies posting jobs on HN. Basically, Who is Hiring provides an outlet for what would otherwise be spam. Move it off to another site and then non-YC companies will still want to post on HN because that's where the eyeballs are.

The companies posting in Who is Hiring aren't posting on HN because they have no place else to post.

A simple HTML form with options that then posts to that thread and formats would solve the problem.

Then the post is still on HN and is formatted to the spec.

The parameters will need to be extensible and this only kills the proposition imho.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact