Skip to content

What eleven practice runs taught us about job-site forms (plain version)

Engineer version: ../technical/scraper-automation-learnings-summary.md

Over one night, the app practiced filling out application forms on eleven different kinds of job-application websites — the behind-the-scenes systems that power places like Workday, UKG, Greenhouse, Lever, Oracle, SAP SuccessFactors, iCIMS, Paycom, Dayforce, ADP, and Paycor. Every practice run happened against a fake copy of the form on this one computer — never a real website, never a real account, never a real submission. Here's what came out of it.

The big lesson: every website hides its clues differently

There's no single trick that works everywhere. Each of these systems tags its form fields in its own way under the hood, so the "first clue to try" has to be different for each one:

Website Best first clue What it falls back to if that's missing Needs to peek inside embedded windows? What made it tricky
Workday a special tracking tag on almost every field similar tags, then accessibility labels No had to learn to ignore leftover, invisible fields from earlier steps
UKG the field's ID the field's "name," then its accessibility label No site changes screens without a full page reload
Greenhouse the field's ID matching by the label you can see Sometimes custom questions can only be found by their visible label
Lever the field's "name" a few backup tags No custom questions shift position from posting to posting
Oracle (older "Taleo") the field's "name" (ID doesn't work at all here) Yes, deeply ID-based matching failed completely; only "name" worked
Oracle (newer) the field's ID Less so opposite of the older version, despite being the same company
SAP SuccessFactors a partial match on a long generated ID accessibility label, then "name" Yes, often translated into other languages, so anything relying on visible English text breaks
iCIMS a partial match on a long generated ID "name," then accessibility label Yes, sometimes two windows deep the single hardest site — required a whole separate "which window am I actually in?" strategy
Paycom the field's ID "name," then the visible label No accessibility labels are unreliable here, unlike some other sites
Dayforce a testing tag accessibility label, then the field's ID No not a clue problem at all — a timing problem (see below)
ADP the framework's internal binding name the field's ID, then "name" No the field ID is actually the least reliable clue here — the opposite of Paycom

The rule that ties it all together

Figure out which website you're on first, then use that website's best clue — but always keep trying the backup clues too, just in case. Never assume the last website's best trick will work on the next one; two of these were built by the same company (Oracle's older and newer products) and still needed opposite strategies. And never rely on just one clue and give up if it's missing — websites redesign themselves, and the whole point of having backup clues is that the automation doesn't break the day that happens.

Two extra twists worth knowing about

  • Some forms live inside a "window within the window." A few of these sites (iCIMS, SAP SuccessFactors, sometimes the older Oracle product) actually embed the real form inside something like an embedded video player — the automation has to notice that and "step inside" it before it can see any fields at all.
  • Dayforce wasn't a clue problem, it was a waiting problem. Its fields simply aren't there yet the instant the page loads — the site has to finish "waking up" first. The fix was teaching the automation to wait for that to finish before it tries to click or type anything.

Every base has its own write-up

Each hiring-software family got its own practice lab, written up in both a technical and a plain version: Workday, ADP, Dayforce, Greenhouse, iCIMS, Lever, Oracle, Paycom, Paycor, SuccessFactors, UKG, plus the big in-house sites — Amazon, Google, Meta, Microsoft. The technical index links every one: scraper-automation-learnings-summary.md.