Every listing is re-checked continuously, oldest and most-visible first. There are two kinds of check, and the difference is the whole point:

• Against the employer's own hiring system. We ask the ATS directly whether that job is still there. This is the company answering about its own job. If it says the job is gone, we expire the listing immediately.
• By re-fetching the posting page. Occasionally we cannot work out which posting on a board a listing refers to, and then we fetch its page and look for the signs of a removed posting. This is weaker: a filled posting is often redirected to a homepage rather than returning an error, so landing somewhere else is treated as "don't know", never as "still open". It takes two consecutive failures to expire a listing this way.

A listing's page tells you which of the two produced its badge, because "verified" means materially different things in each case.

Listings also age out on their own: unseen at any source for three days they go stale, and expire a few days later. Age alone never expires a listing whose posting the employer's board still carries — an age is a guess about whether a job is filled, the company still advertising it is evidence, and evidence wins. That is why some listings here are months old and still marked open.

A posting carries a location tag from the employer's own board. That tag is frequently wrong — a role tagged "Anywhere" that turns out, nine paragraphs in, to require authorisation to work in one country. So we read the ad itself, and we keep the two answers separate:

• What the source tagged, which drives the location filter.
• What the ad's own text says, read out of the description.

When those disagree we show both and flag it, rather than silently picking one. That is the ⚠ ad says … badge, and the listing's page quotes the sentence that produced it so you can judge it yourself in a few seconds.

We only look for restrictions, and we would rather find none than find the wrong one — a wrong country hides a job you could actually take. So a preference ("ideally EMEA") is not a restriction, a mention of a company's head office is not a restriction, and a pay band or privacy notice that happens to name a country is not a restriction. Where an ad names more places than we can read cleanly, we record nothing rather than record half a list. About one posting in ten states a restriction we can read with confidence.

Every source we read is an employer's own board, and we pull each company's entire board — so office and hybrid postings arrive alongside the remote ones and have to be told apart. Nothing here is remote by construction.

Rather than a yes/no rule, signals accumulate into a confidence score. The location string an employer publishes is the strongest evidence — "Remote - USA" versus "Bangalore, India" comes straight from the company. Wording in the title counts, because "(Remote)" is rarely accidental. Wording in the description counts for very little on its own, since office postings routinely carry "we're a remote-friendly company" boilerplate. Anything naming hybrid or in-office days outweighs every positive signal.

Each listing says which evidence its answer rests on, in the panel beside the ad, because "remote" deserves the same treatment as "still open":

• A location the employer published — "Remote, Poland", "Remotely in Germany". We print it exactly as they wrote it, because re-wording an employer's location and then attributing it to them is its own kind of dishonesty.
• A remote setting on their board — a field the company filled in rather than wording we interpreted. Common where the location field names the office the team sits in.
• Neither — the answer comes from the title or the description, and the listing says so plainly and tells you to read the ad. This is the only one of the three that is our reading rather than the employer's statement, and it is labelled as ours.

Listings below the threshold are kept but hidden, with the reason recorded, so mistakes can be found and the rules corrected against real data rather than guessed at.

A comparable set is the same functional area and region, inside a single currency and a single period, over figures the employer disclosed. Where the title states a seniority and enough comparables share it, the set narrows to that; otherwise it covers every level and says so. We publish the middle 50% — the range the 25th to 75th percentile of those listings fall in — and print the number of listings behind it.

Four rules decide whether a band appears at all, and each of them removes bands we could otherwise have shown:

• Never converted. A band is computed inside one currency and one period and labelled with both. An exchange rate baked into a stored figure is wrong the next day and silent about it; an hourly rate multiplied out invents a number no employer offered. Where a market is too thin to reach the minimum inside its own currency, we publish nothing rather than borrow another one.
• At least eight comparable listings. Below that the percentiles describe the sample rather than the market.
• Wide bands are withheld. If the middle 50% spans most of its own midpoint, the answer is not informative — it merely looks precise. Those are dropped rather than shown with a caveat.
• Only disclosed figures, from sources we still trust on pay. A board's own salary estimate never enters a comparable set, and neither does any source our accuracy checks have restricted on salary. Always-open pipeline listings are excluded on both sides.

A band never appears on a listing that states its own pay, and it never affects the salary filter or the ordering of results — those work on published figures only. It is an answer to silence, not a second opinion about an employer who has spoken.

Match your CV

Paste the text of your CV and we read skills out of it with the same vocabulary we read job ads with, then find open listings sharing at least three of them. Any level, location or pay filter you set applies first. There is no file upload, deliberately: an upload is a temporary file on a disk somewhere, and the surest way not to leave one behind is never to create it.

The answer is "6 of 9 skills matched" and the names of the three that did not — never a percentage and never a score. A percentage reads as a probability of being hired, and nothing here is calibrated to support that claim. At most 300 matches are shown; past that, narrowing by location or level is the honest way further in rather than a longer list ranked by a signal that has stopped discriminating.

Your CV is not stored. It is read in memory, matched and discarded. Moving between pages of your results re-uses the skills we already extracted — shown to you as chips — rather than the CV, so the text is read once and never sent again. The page is rate-limited and carries a bot challenge, because an endpoint that accepts pasted text is worth protecting from everyone except the person it was built for.

Saved jobs and saved searches

Both lists are kept in your browser's own storage. No cookie, no identifier, and no record on our side of what anybody saved — which is also why they do not follow you to another device, and why clearing your browser data clears them.

A saved job is stored as the listing's number and nothing else. When you open the saved page, those numbers are sent to us and the cards are rendered fresh — we deliberately do not keep a copy of the card beside the number, because a copy renders instantly and then goes quietly out of date, and a shortlist that goes on saying "still open" about a job filled last week is the one failure this site exists to prevent. They are sent in the body of a request rather than in the address bar, so the set does not land in a web server's log.

A saved search is the filters you had set, plus a label in your own words — so each one is also a link you can share or come back to. You can keep 5 jobs and 3 searches, and both lists can be exported as JSON or cleared outright. If a listing you saved has since been merged into another we re-point it silently, because that is bookkeeping; if we removed it from the catalogue altogether we say so rather than shortening your list without telling you.

Email alerts

An alert is attached to a saved search, from the bell beside it. Signing up sends exactly one confirmation email, and nothing further is sent until you press the button in it. If you never do, the request is deleted after seven days and you hear nothing more. Repeat signups are limited to one per address per hour, so the form cannot be used to send mail to somebody who did not ask for it — and it answers the same way whatever happens, because telling you whether an address is already subscribed would answer that question for anybody who can type.

Alerts are weekly, and weekly is the only cadence on offer. Instant alerts and notifications when a role you applied to closes are planned as a paid feature and are not running yet; nothing here will claim to send you either.

There is no login anywhere on this site. Every message carries a link that manages the subscription, and that link is the whole of account management — which is what removes passwords, resets, sessions and account takeover in one decision. Removing the saved search does not stop the alert — the search is in your browser and the subscription is on our side with your address attached, so deleting the one cannot reach the other. Stopping an alert takes one click from any message and deletes the subscription outright: the address, the search and the record that you opted in. One thing outlives it, a keyed one-way hash of your address meaning do not write here, so that nothing can quietly add you back. Signing up again and confirming is what reverses that.

Light and dark

The moon in the header switches to the dark theme and the sun switches back to the light one, and your choice is remembered in that browser. Until you make one, the site follows whatever your device is set to.