Why "one-click apply" still makes you retype everything

Because the upload and the form were never connected. The parser fills the handful of facts a document can supply — name, email, phone — and then stops, because everything else the form asks is not in a résumé and could not be. Then you retype it, at the next employer, into a field with a completely different name that means exactly the same thing.

That second half is the part with a fixable cause, and it took taking six ATS vendors apart to see it properly.

Almost nothing on the form is in your résumé

Look at what a real application asks that a CV does not contain: your notice period. Your salary expectation. Whether you require sponsorship now or in the future. How you heard about them. Whether you have worked here before. Whether you are within four hours of Central European Time. Which of their four office locations you would consider.

None of that is in a document about your work history, and no amount of parsing will produce it. So the upload fills three boxes, and the rest of the form sits there, and it feels like the site is being obtuse when actually it is asking you things only you know.

The three it does fill are the three it always gets right, which is why the experience is so annoying. It solves the easy part in front of you and leaves the tedious part untouched.

The field ids are minted per employer, per question

Here is the same question — "How did you hear about us?" — as five different boards name it in their payload:

• Greenhouse: question_64549956
• Ashby: a bare uuid, or a _systemfield_* token for the standard fields
• Lever: cards[6f2a…][field0]
• Workable: QA_1039
• Rippling: a uniqueKey uuid
• Personio: custom_1, with the wording not published at all

Nothing there carries. Two employers asking a character-for-character identical question use different ids, because the id was generated when that recruiter added that question to that form.

It goes one level deeper. The answers are minted per employer too. On Greenhouse the option list for a custom question is integer ids, so "LinkedIn" is a number at one company and a different number at the next — in one Stripe payload we found integer option ids on a custom question, the integers 1 and 0 on a yes/no question, and string ids on the EEOC block, all three in the same response. Storing the value you picked last time teaches a tool nothing that survives to the next form.

That is the whole mechanism behind the retyping. It is not laziness on anyone's part. There is simply no shared vocabulary, because no one ever had a reason to build one.

The one thing that does carry is the words

The ids are per-employer. The wording is not — it is copied verbatim between recruiting teams, because that is where forms come from.

So Crossing keys remembered answers on the normalised text of the question rather than on the board's field id. Strip the markup some boards wrap questions in, decode the entities, fold the smart quotes, remove the leading politeness that varies between boards asking the identical thing (Please , Optional: , Q1. ), drop the punctuation, lowercase it, collapse the whitespace. What is left is a key, and it is the same key at every employer that asks that question.

That is why the second application is genuinely faster than the first, and the fifteenth is faster than the second. Not because anything got smarter — because the second employer's question_88104412 normalises to the same string as the first employer's question_64549956.

The system also refuses to mint a key in four cases, and the refusals matter as much as the matching:

• Consent boxes. consent[marketing] on Lever, gdpr_consent on Workable, opt_in_talent_community on Greenhouse. A permission given to one company is not a permission given to the next.
• Written answers. Anything typed as a textarea and not recognised as a standard field is an essay. Replaying one verbatim is the generic-cover-letter failure.
• Questions naming the employer. "Why Notion?" normalises to a key that would collide with "Why Linear?" if we let it.
• Work-authorisation questions naming no country. "Are you authorized to work in the country for which you applied?" has a different right answer per posting.

Why a browser autofill extension does not fix it either

Password managers and browser autofill match on field names, autocomplete attributes and nearby label text. Modern ATS front ends supply almost none of that.

We measured it while building our own fill:

• Ashby renders a React form with no stable name attribute on the inputs.
• Workable's apply page is a 7KB shell with not a single <input> in it — the form is drawn later, client-side.
• Rippling's application page contains no <input> at all, same reason.
• Greenhouse does render ids, and two of them are not valid CSS identifiers on their own: a multi-select keeps its trailing brackets (question_67879167[]), and a demographic question's id is a bare number (1478), which a CSS selector cannot start an identifier with.

Where we know a selector, we ship it. Where we do not, our form description carries an empty list, and the fill falls back to matching the visible label. We would rather publish "unknown" than a guessed selector that reads as verified.

What "one-click apply" means on a job board

It is worth being precise here, because the phrase covers two different things and only one of them reaches the employer.

On an ATS board — Greenhouse, Ashby, Lever — a fast apply means the form is short and you are filling in the employer's own system.

On an aggregator it usually means the aggregator is handling the application itself. From our own resolution pass over the boards we index:

• RemoteOK hosts the application on its own site.
• We Work Remotely handles the application itself.
• Himalayas requires a Himalayas account before it will show you the employer's link.
• Jobicy publishes no apply link.
• Remotive's apply button is not a link.

None of those are bugs. They are the business model — the board's value is the relationship with the employer, and giving you a direct line spends it. But it does mean "applied" on those sites is not the same event as "applied" on the employer's board, and it is worth knowing which one you just did. We ranked the boards on exactly this in remote job boards, ranked by whether you can reach the employer.

And the last click stays yours

Filling the form is a solvable problem. Submitting it is not, and we are not going to pretend otherwise: every one of these vendors gates submission behind a captcha bound to its own origin, and every documented server-side submit endpoint authenticates with a key issued to the employer. So Crossing fills the employer's real form, opens it in your browser, and stops. The long version is here.

The retyping, though, was never load-bearing. It was just an accident of nobody agreeing on a name for "How did you hear about us?".