I run a system that fills in job application forms on company hiring platforms, all day, across the twelve systems most companies actually use.
Greenhouse, Lever, Ashby, Workday, iCIMS, Personio, Teamtailor, SmartRecruiters, Recruitee, Breezy, Workable, Rippling.
Which means I have watched, in logs, the thing you never get to see: the sixty seconds after you press the button.
Here is the real sequence.
Four of these six steps can drop you without anybody deciding anything about you.
1.
The file is parsed, not read The first thing that happens is not a person.
It is a parser pulling a text layer out of your PDF.
This is the step that eats people alive, because a PDF can look perfect and contain no text at all.
If your resume was exported by anything that renders the page to an image, a design tool, a screenshot, some web builders, then the file is a picture.
The parser extracts nothing, and your application arrives as a blank form with your name on it.
Ours did this.
For months.
Our own export produced a PDF with zero text-showing operators inside it, a JPEG in a PDF wrapper, and our own importer read it back empty.
A real person then retyped their entire history by hand rather than fight it.
Check yours right now.
If you have , run .
Under a hundred bytes means you are sending a picture.
If you do not, open the PDF in any viewer and try to select a line of text with your cursor.
If nothing highlights, no parser can read it either.
That one check is worth more than any keyword advice you will read this year.
2.
The parse is mapped to fields The parsed text gets mapped into structured fields.
Name, email, employers, dates, titles, education.
Two-column layouts, tables and text boxes are where this goes wrong, because reading order in a PDF is not visual order.
A parser walking the content stream can interleave your left column into your right one.
Your five-year role at one company becomes three months at another.
Single column.
Real headings.
Ordinary dates.
This is not a style opinion, it is a parsing constraint.
3.
Knockout questions run before any human is involved Work authorisation, notice period, location, salary expectation, sometimes a years-of-experience number.
These are evaluated by rules the recruiter configured, and they run before a person opens anything.
A blank answer here is not neutral.
Many of these forms treat an unanswered required question as a disqualification rather than an omission, and the form itself will often refuse the submission entirely.
This is where a lot of "I applied and heard nothing" actually happens, and it is invisible from the outside.
There is no message.
There is no rejection.
The application simply never enters the queue a human looks at.
4.
The form validates, and can refuse you politely The form runs its own validation, and it does not always tell you the truth on screen.
We have watched a hiring system return a perfectly clean confirmation page while separately recording a refusal for the same submission.
We have watched a form refuse a complete application, with every field filled and a valid token attached, purely on an automated reputation score.
The reason came back in the response body: the score was below the threshold.
Nothing about the application was wrong.
If that can happen to a system built to watch for it, it is happening to people who cannot see the response body at all.
5.
The acknowledgement is sent, or it is not If the submission is genuinely accepted, the system sends an automated acknowledgement.
It arrives fast, seconds to a couple of minutes, from the vendor's domain or the company's.
This email is the only proof you will ever get that your application exists.
Not the thank-you page, which is rendered by the same code that can refuse you afterwards.
Not your own sense that it went fine.
The reply.
If you apply somewhere and no acknowledgement arrives within a few minutes, treat that as a fact about the submission and not a fact about your candidacy.
Apply again