Automating Greenhouse applications

Greenhouse-hosted applications tend to present a single application form rather than a long multi-screen wizard, and frequently do not require the candidate to create an account first. That removes two of the largest sources of automation failure at a stroke.

It also means less state to manage. There is usually no session to keep alive across five screens, so the agent’s job narrows to reading one form correctly and filling it accurately.

That narrowing has a practical consequence for design: this is a flow where a deterministic script is genuinely viable. Once the field mapping for the standard section is known, there is little left for a model to reason about, and reserving the expensive path for the custom questions alone is a large cost saving.

Employers often embed the application inside their own careers site rather than sending candidates to a hosted page. The surrounding page is the employer’s design, while the form itself comes from the platform.

An agent should detect the form’s origin rather than judging by the page it appears on. Otherwise it treats every employer site as unique and re-derives a structure it already knows how to handle.

Detection is usually cheap. The embedded case loads the form from the platform’s own domain, and the field naming convention inside it survives the employer’s styling — so a single origin check does the work that page-appearance heuristics do badly.

• Detect the form source, not the host page branding
• Expect the same field semantics under different styling
• Handle the hosted page and the embedded case with one handler
• Fall back to generic form reasoning only when detection fails

Because the standard fields are simple, the differentiator is the employer-added questions — why this company, describe relevant experience, a short scenario. These are free text, they are read by a person, and they are the part of the application that is actually evaluated.

An agent that fills these with generic text has automated the submission and destroyed the application. Generate from the candidate’s real history against this specific posting, and if there is nothing genuine to say, surface the question to the candidate instead of producing filler.

Worth understanding why employers add them at all. A custom question is deliberate friction — a filter that costs the employer nothing and costs an automated applicant either real effort or a visibly hollow answer. Treating it as one more field to populate is missing the entire point of its presence.

File upload fields have their own constraints — accepted types, size limits, occasionally a required cover letter. A failed upload that the agent does not notice produces a submitted application with nothing attached.

Verify after uploading that the file is registered in the form, and treat a missing attachment as a stop condition rather than something to submit around.

Demographic and voluntary disclosure questions sit alongside these and are not the agent’s to answer. They are a personal declaration, they are explicitly voluntary, and an agent that infers a response is making a statement about someone to their prospective employer without being asked to.

Because the same custom questions tend to recur across a company’s postings, the highest-value thing an agent can store is the candidate’s previously approved answers keyed by employer and question. The second application to the same company should be nearly free.

Store the question text alongside the answer, not just a field identifier, so a reworded question can be matched by meaning and flagged for review rather than silently answered with a response to a different question.

Keep the submission record too: which posting, which document version, what was written in each free-text box, and when. That record is what lets the candidate walk into an interview knowing what the interviewer is reading.

• Approved answers keyed by employer and question text
• The exact CV version attached to each submission
• A per-employer application count, to enforce a sane cap
• Any question that was surfaced to the candidate and why

A low-friction form makes high-volume submission technically trivial, which is exactly the situation in which quality collapses. The employer still receives a real application from a real named person.

Keep the confirmation step even when the form is simple, cap volume per employer, and hold the same standard for answer quality that you would on a harder portal. The ease of the mechanism says nothing about the appropriateness of the application.

The per-employer cap is the specific control that prevents the most visible failure. Six applications to six different roles at the same company, submitted the same afternoon, arrive in one recruiter’s queue and are read as a single unserious candidate rather than six chances.