List is very US-centric

[FLamparski]

I count just 11 companies out of the 382 listed that have offices in the UK (bias: I live there), 21 offer remote working arrangements. Not all programmers live in California, you know ;)

Suggestion: split up the list by country - this will also allow greater specificity within the location field. Yes, multi-location companies may have to be repeated, but I think it would still be more searchable that way. This also instantly helps people narrow down their choices to countries they can easily obtain right to work in (ie. EU nationals can move to another EU country (exception: countries that shot themselves in the foot, like the UK) and just start work there, but moving to California requires a green card or H1B (is that what it's called?)).

[j-delaney]

I agree completely that this list needs a lot more diversity w.r.t. location! A lot of that is my fault. The majority of companies on this list were added by me and my method was just checking random companies to see if they had a good application process. Being a California/US based developer, the companies that came to mind most often were California/US companies.

I would love to see this list expanded to encompass more non-US companies. Unfortunately, I can't do it on my own. I happily accept Pull Requests that add more companies. To encourage more of those, what do you think about adding a note to README.md asking users to contribute more companies (especially non-US ones)?

The idea of splitting the list by country/other attributes has been suggested before. I've turned it down because I want to keep the list easily machine-parseable. @pankajpatel recently submitted an awesome PR that creates http://j-delaney.github.io/easy-application/ which allows users to filter by city. I'm hoping that this can be expanded to let users filter by country and other options. Any feedback you have on this would be greatly appreciated!

[NerdDiffer]

@j-delaney, last week I made a parser for this list. It downloads the markdown file, saves to local disk, reads & parses each row in the table.

From that point you can filter companies by any available property on location:

• city, state, country
• remote (true or false)

I made some judgement calls when it came to structuring the data and I would be happy to incorporate to your feedback.
The module works right away for node & command line scripts, but can certainly be expanded. Think there would be any value in this?

[j-delaney]

@NerdDiffer That's really awesome! It okay with you if I link to your repo from easy-application's README? I'm going to be writing a script to enforce formatting on the table itself because I want to make it as easy as possible to parse it. Do you have any ideas on that? Things that would make scripts like your have an easier time.

[NerdDiffer]

@j-delaney, yea that's totally OK to link the parser repo from this README.
Parsing locations can be tricky, especially for foreign countries.

For instance, my script wrongly interprets NL, HK, CN to be part of the USA. I made an exception for UK, but I don't want to keep playing whack-a-mole with country names. I suppose I could whitelist all 2-letter abbreviations for American states & the DC in 'Washington, DC', and then assume anything else to be a foreign province or country name.

edit: just fixed the bug described in previous paragraph.

There'd still be a few mistakes, such as CoreOS, where one location is listed as "Berlin, DE". Are they hiring in Berlin, Germany or in Berlin, Delaware? Not sure that the latter is a real place!

So, given that most companies in the list right now are in America, I'll suggest:

• the country is assumed to be USA unless stated otherwise.
• Any abbreviations for names of foreign countries which could be mis-interpreted as an American state to be off-limits, for example: 'Berlin, DE', or 'Toronto, CA'. Instead, favor writing: 'Berlin, Germany', 'Toronto, Canada'.
• However, if there's a matching abbreviation for a foreign province, such as "Florianópolis, SC, Brazil", that is OK, because of "Brazil" at the end.

[pankajpatel]

Or we can combine both gh-pages and parser from @NerdDiffer.

In the background, we can make an app that uses the parser to structure data and webpack bundler will easy usage in the gh-pages viewer.

[pankajpatel]

We can go forward with this as https://github.com/pankajpatel/easy-application/tree/master/docs

[j-delaney]

@NerdDiffer Thanks! I'll let you know once I've made all the data consistent and the format validator is live.

@pankajpatel Thanks for building that, but something I'm really trying to push with this repo is keeping things simple including the gh-pages. Webpack + package.json goes a bit too complex for my liking. I'd very much prefer to keep it just an index.html and single JS file. I really do appreciate you building that though