Skip to content

Microsoft Careers Scraper Automation Learnings

This is a local training lab for a Microsoft-style careers application flow. It never visits the real Microsoft careers site. It starts a tiny local web server on 127.0.0.1, fills fake fixture data, and stops at review.

Selector strategy

Microsoft's careers flow is custom. It is not Workday, Greenhouse, Lever, iCIMS, or another standard ATS. The lab therefore tries selectors in this order:

  1. clear ids, like firstName
  2. clear names, like degree
  3. aria labels, like First name
  4. nearby labels, like a First name label followed by an input

The engine always uses the first visible match. This avoids filling hidden controls from earlier steps that are still present in the page.

Fallback chain

Each run changes the fake page. Sometimes ids are present. Sometimes ids are renamed. Sometimes only aria labels remain. Sometimes optional fields are missing. That makes the selector chain prove it can fall back instead of relying on one lucky id.

The submit button is different. The lab finds it, logs would submit (suppressed), and does not click it. The button itself also returns false, and the submit route is a no-op.

Timing quirks

Some fixture runs delay the next step before showing fields. The runner waits for the current step to become active, then resolves fields with short selector timeouts. This tests slow page transitions without making the lab slow.

Hit-rate numbers

The 20-iteration run prints a summary with:

  • completed runs
  • judgement pauses
  • suppressed submits
  • submit controls located
  • primary selector hits
  • fallback selector hits
  • failure modes

Verified run on July 4, 2026 with --iterations 20 --seed 1337:

Field Attempts Match rate Primary hits Fallback hits
Account continue 32 62.5% 8 12
Account email 42 47.6% 3 17
Account password 33 60.6% 11 9
Address 44 38.6% 9 8
Degree 32 62.5% 11 9
Employer 36 55.6% 10 10
First name 41 48.8% 6 14
Last name 35 57.1% 9 11
Next / Continue 80 100.0% 80 0
Phone 44 38.6% 8 9
Relocation preference 32 62.5% 12 8
Resume upload 26 76.9% 14 6
School 37 54.1% 8 12
Submit button 20 100.0% 20 0

Overall: 20 iterations, 20 completed, 0 faulted, 18 judgement pauses, 20 submit controls located, and 20 suppressed submits.

Why Microsoft is a prime PageAgent-advisor case

Microsoft's custom DOM is a strong case for a PageAgent advisor because not every field is a simple contact field. Degree and screening questions often require judgement. The lab pauses with RunStatus.AwaitingJudgement and stores the question in ApplicationRun.PendingCall.

The IPageAdvisor seam being built on branch feature-pageagent-swap can attach to that pause without changing this lab. It can read the visible page, rank the choices, and hand the decision back while the submit guard still prevents any final submission.