Your Req Closed in Two Days: Did You Select for Bots?

What did a two-day cap actually select for?

Arrival time. A count-based cap closes the moment the counter hits its number, so the group you kept is whoever landed before that instant. Four things shape that group: when the post went live, which job alerts fired on it, which aggregators re-listed it, and which candidates had software submitting for them. Fit appears nowhere on that list, and neither does interest in your company.

The machine end of it is not hypothetical. LinkedIn's own job-competition measure describes nearly 10,000 members applying for jobs on the platform every minute ¹, and the auto-apply tools sold to candidates advertise the mechanism plainly: one of them says a subscriber's copilot searches for new postings every two hours and auto-fills the application forms, up to 20 jobs a day on its Premium tier and up to 50 on its Elite tier ². Somebody running that entered your req at the top of the queue without reading it.

But "whoever's bot was fastest" overstates what happened. Most of your first hour is ordinary people whose alert email arrived, and the timestamp cannot separate them. A 09:00:11 submission looks identical whether a person was refreshing the page or a scheduler fired. Sorting the two apart from the arrival log is not possible, which is precisely why the log is the wrong thing to select on.

Two quieter distortions ride along with a first-come close. Time zone: a req that opens at 09:00 Eastern takes its first two hours from people awake and at a screen in North America, and the same posting opened at 18:00 takes a different set entirely. Employment status: somebody between jobs checks alerts hourly, somebody doing your job today checks them on Saturday morning. Neither fact says anything about who does the work better.

This is also a different question from how a screening tool orders the resumes it does read. The cap runs earlier than any of that. It decides which applications exist for you at all, and the volume that made a cap look necessary came mostly from real people applying to more roles, not from a wave of fake ones.

Measure the posting's arrival curve before changing anything

Pull the submission timestamps off the closed req and chart the share by hour. One number decides whether the cap hurt you: the advance rate of applications that arrived after the first twelve hours, against those that arrived before. If the later ones reached a phone screen at the same rate or better, the early close cost you candidates, and you now know roughly how many.

Three cuts, all of them in an ordinary ATS export:

• Share by hour, for the first 72. Front-loading is normal; the slope is the question. An alert-driven curve spikes inside the first ninety minutes, decays, then bumps again twelve to sixteen hours later as overnight digests fire in other time zones. A curve that stays flat means people went looking for your role specifically.
• Volume by source, on the same clock. If one aggregator supplied most of the first six hours, the cap is a distribution problem rather than a market problem, and the fix is a per-source limit rather than a shorter window.
• Advance rate by arrival cohort. Split the applications into first-day and after, then compare the share that reached a screen, an onsite, an offer. The counts on one req are small, so read it as a direction and repeat it across three before believing it.

Run the same arithmetic on what the cap saved, because that constraint is real and deserves a real answer. A cap exists because reading time is finite: 400 applications at 90 seconds each is ten hours of work. Closing early solves those ten hours by sampling on the wrong axis. The same ten hours spent on a checkable filter (work authorization, location, the licence, the one system the job runs on every day) cuts the pool on facts and leaves arrival order out of it.

If the instinct is to tighten the automated filter instead, that lever is already spent: every application now contains every keyword in the posting, because the model that wrote it read the posting first.

Is a first-come cutoff a selection procedure?

Treat it as one. Under the Uniform Guidelines on Employee Selection Procedures (United States federal, 29 CFR part 1607, adopted 1978), a selection procedure is any measure, combination of measures, or procedure used as a basis for any employment decision, and the definition reaches down to informal or casual interviews and unscored application forms ³. A cutoff deciding who gets considered sits inside that.

Three consequences follow, and none of them needs a lawyer to start on:

• Keep the impact records. The Guidelines say each user should maintain and have available for inspection records disclosing the impact its tests and other selection procedures have on employment opportunities by identifiable race, sex, or ethnic group ⁴. That does not skip the cutoff because the cutoff feels administrative.
• Know the benchmark. A selection rate for any race, sex, or ethnic group below four-fifths (80%) of the rate for the group with the highest rate is generally regarded by the federal enforcement agencies as evidence of adverse impact ⁴. Run that comparison on the window itself, not only on the interview stage.
• Have the job-relatedness answer ready. Neutral procedures that disproportionately exclude people on race, color, religion, sex or national origin have to be job-related and consistent with business necessity, and the employer stays responsible for that even where an outside vendor supplied the tool ⁵. The cap is usually a vendor's ATS setting that nobody chose.

That third one is where a timestamp struggles. Business necessity is argued as necessity to the safe and efficient performance of the job ⁵, and there is no version of that sentence ending in "and applied before the counter filled." A work sample has the argument available to it. An arrival log does not.

Everything above is public law rather than legal advice, and the automated-decision rules now in force in individual states carry their own requirements on top of the federal ones. Before you change a posted process, put the question to counsel with the arrival data attached. That conversation is short when the numbers are already in the room.

Replace the counter with a window, a draw, or a work act

Four replacements, ordered by what they cost you. Post a fixed window and close on the clock. Cap each source separately instead of in aggregate. Draw at random from everyone who cleared the hard requirements inside the window. Or attach a short work act and set the cap on completed tasks, so the allowance goes to people who did something rather than to people who arrived first.

• A fixed window, closed on the clock. "Open through Friday 17:00 Eastern" in the posting, and the counter comes out of the ATS. What it selects on: nothing. What it costs: everything that arrives still has to be read, so on its own it relocates the problem instead of solving it. Right when the cap existed only to keep a recruiter's queue bounded.
• Per-source caps. One limit per source rather than one in aggregate, so a single aggregator cannot spend the week's allowance before lunch. Cheapest of the four, usually one setting, and it protects the sources you actually invested in: referrals, the careers page, the community you post in. What it costs: inside a source, first-come still decides.
• A random draw inside the window. Everyone who clears the checkable requirements goes into the frame, and you draw the number you can genuinely process. What it costs: you have to say it in the posting in plain words, and you have to be able to show afterwards who was in the frame and how the draw ran. A recorded seed and a timestamp is enough; an unrecorded shuffle is not. It also discards arrival order, which carries a little information about how much somebody wants the job and none about whether they can do it. Right when qualified volume runs several times your capacity.
• A short work act as the cap. Ten to twenty minutes attached to the application, with the allowance set on completed tasks. What fills the cap is now an act, and it is the only one of the four that leaves you something to read. What it costs: candidate time, which you spend honestly by saying up front what the task is and how long it takes; plus an answer key, without which you have swapped a timestamp for an impression. Build it so an assistant may be used in the open. A task a model finishes in thirty seconds measures nothing at all. Dropping the resume screen for a work sample is the same trade at full scale, with the volume math worked through.

Whichever one you take, it belongs in the posting before it runs, written for the applicant rather than for the ATS: when the window closes, what happens to the applications inside it, and when to expect a reply. A rule stated in advance is a rule. The same rule discovered afterwards is a reason to distrust everything else on the page.

Don't make the fast applicants the problem

Nobody broke a rule you had written. Auto-apply exists because a considered application costs an hour and usually gets no reply, and the candidates using it include people you want to hire. It is unenforceable at your end anyway. A timestamp tells you when something arrived, never what produced it, so the durable move is a window you can defend rather than a ban you cannot police.

The evidence runs against treating tool use as a defect. In a field experiment across nearly half a million job seekers in an online labor market, treated job seekers were hired 8% more often after algorithmic writing assistance, and there was no evidence that employers were less satisfied afterwards ⁶. The authors' explanation is that better writing does not signal ability, it helps an employer make out the ability already there. An AI-written application is not a reason to reject anyone on its own, and the same reasoning covers the one that arrived quickly.

What you write while you decide matters too, because candidates read the posting, the rejection note, and each other's screenshots of both. A line saying the req closed early because of bot applicants tells four hundred people you assumed they were bots, when most of them saw an alert. "Open through Friday, then closed to new applications" says the same operational thing and accuses nobody.

What is worth screening hard on has not changed: work authorization, location, the licence, the system the job runs on every day. Those are facts, they are checkable in seconds, and they hold up when a candidate asks why. Arrival speed does none of that work.

Then name the real loss from the two-day close, because that is the version a hiring manager acts on. It is not the automation you let in. It is the person who heard about the role on Wednesday from somebody who already works there, opened the link, and found it closed.

See a sample report >