How fast does HireSalt score resumes? Three timed runs
The HireSalt team 4 min read
In three timed runs on 16 October 2026, HireSalt scored every resume in piles of 25, 50 and 100, with no failures. The rates were 271, 252 and 392 resumes per hour. The rate varied from run to run, from 252 to 392 an hour. Our homepage quotes the 100-resume run: up to 390 an hour, which is 391.8 from the raw timings, or about 388 with the criteria step counted.
| Pile | All scored | First score | Resumes per hour | Failures |
|---|---|---|---|---|
| 25 resumes | 5.5 min (332.2 s) | 28 s | 270.9 | 0 |
| 50 resumes | 11.9 min (714.3 s) | 20 s | 252.0 | 0 |
| 100 resumes | 15.3 min (918.8 s) | 18 s | 391.8 | 0 |
How we ran it
All three runs used the same software engineer job description from our test set and our production scoring model at its default effort, through our production gateway. Each pile went through the same batch scoring code that a recruiter’s upload starts, on a fresh database. We started the clock just before scoring began and checked the database every 2 seconds. “All scored” is the first check at which every resume had a score. Resumes per hour is the number scored divided by that time.
The 100-resume pile held the 20 software engineer resumes in our set plus 80 drawn at random from other roles. The 25 and 50 piles were drawn at random, with no overlap, from a pool of 220 resumes, so most of their resumes were also for other roles.
Before each run we wrote down a pass rule: every resume finishes within the time cap, and no more than 5% fail. All three passed with zero failures. The 100-resume run went first, at 02:36 India time, then 25 at 03:09 and 50 at 03:16.
The job’s scoring criteria were drafted before the clock started, which took 9.2 to 11.6 seconds per run. In the product this happens when a recruiter creates the job, before any resumes arrive. If you add that step to the clock, the 50-resume run comes to 248 per hour and the 100-resume run to about 388.
Why the 25-resume figure is on hold
Our written plan for the 25 and 50 runs allowed a headline only for the 50-resume run. The 25-resume run passed its own rule, but in our list of usable figures it is marked “hold”: we do not quote it as a headline on its own. We include it here so the full spread of runs is visible, not only the fastest.
What this does not show
- One job, one night, one run per pile size. Three runs are not a spread of conditions.
- A shared gateway. The gateway also served live users, and we do not know how busy it was. The median scoring call took 18.1 seconds in the 100-resume run, 23.5 in the 25 run and 28.0 in the 50 run. The largest pile was the fastest per resume and also had the quickest calls. We have not isolated why the call times varied.
- Two calls at a time. We capped scoring at 2 model calls in parallel to protect live users. A different cap would give a different rate.
- Scores only. The Career Story written after scoring was not finished within the measured time.
- No extrapolation. We did not test 500 or 1,000 resumes, and the rates should not be multiplied out to them. Upload time is not included either.
- First score is not instant. It came at 18 and 20 seconds in the 100 and 50 runs, and at 28 seconds in the 25 run.
A related speed test that failed
In the same session we timed how long a pasted job description takes to become an editable scorecard. The rule was 5 of 5 within 300 seconds. Four did, in 12.0 to 18.5 seconds. The fifth came back with a single criterion, which the app refused to store and queued for a retry. That missed our rule, so we do not quote a scorecard time. More on drafted criteria is in do AI-drafted criteria match the role?.
Related tests
All results are on the benchmark results hub. See also how consistent AI resume scoring is and what happens to unreadable resume files.