Resume Files HireQwik Cannot Turn Into a Shortlist

A HireQwik resume file that never reaches the shortlist is usually telling the truth. The one that still bothers me was named Resume_final_v3.pdf. Thirty-nine other files in that batch became people, with emails and scores. This one stayed a filename, with a blank email and no number beside it. The recruiter’s first theory was that the shortlist cut had hidden a weak score. It had not. There was no score. The file had never become a candidate the ruler could judge.

This post is the failure list for direct upload. The happy path, from a good PDF to a mark on the shortlist, is in the folder-to-score map. Read that if the batch mostly worked. Stay here if a slice of the folder vanished or froze as filenames.

Files HireQwik rejects before a row exists

Some problems never become candidates. That is better than a fake row, and it is easy to miss if you only stare at the review table.

The type has to be PDF or DOCX. A .doc, a .jpg, a .zip, or a file with no extension is rejected with the name and the reason. It will not sit in the shortlist as a zero. If your count of people is lower than your count of files, check the rejected list from the upload before you assume someone was scored and cut.

Size is next. One file over 10 MB is refused on its own. If the combined upload passes 500 MB, or you hand in more than 500 files, the job is refused. I have seen a single portfolio PDF with embedded images blow the per-file line while the CV inside it was two pages. Export a text PDF. Do not compress by photographing the screen.

Identical bytes are skipped, not rejected with a speech. The second file is dropped because its hash matches one already accepted. You will not see a duplicate row, and you may not see a loud error. If you uploaded 40 files and the job says 39, look for a copy-paste twin before you look for a scoring bug.

Rows HireQwik creates but cannot score

A file that passes those gates still gets a row. The name starts as the filename without .pdf or .docx. The email starts empty. That is a placeholder, not a result.

Scoring needs text. HireQwik extracts text from the bytes. If the extractor returns nothing useful, or fewer than fifty characters, the status becomes parse failed. The error summary is stored on the row so you are not left with a blank failure. The placeholder name remains, because there was nothing reliable to write over it. No score is stored. The shortlist cut never sees this person. A cut only marks rows that finished with a number.

This is the scanned-CV case. The page looks complete to a human. A photo of a printed resume often has no text layer. The same miss shows up when a sheet points at an unreadable file, which we described in a candidate who looks stuck in the pipeline. On the Shortlist screen you do not have to guess. Filter away from the completed scores and read the failed rows.

A short text file can fail the same way. A PDF that only says “Resume available on request” will not clear 50 characters of useful content. I would not lower that bar. A score on a sentence is a fiction.

What a failed file does to the HireQwik shortlist

The shortlist is not “everyone except the people we disliked.” It is each finished score that met or beat the cut. The default cut is 60. Parse failures are outside that set. If you export only the shortlist, the failures are absent, and an absent student looks like a rejection. They were not rejected on merit. They were unread.

I export two lists after a messy folder. One is the shortlist, sorted by score. One is the failures, with the error summary. The second list goes back to the sender: placement cell, vendor, or the candidate. The ask is specific. Send a text PDF or a DOCX under 10 MB, one file per person, not a scan. Then run those replacements as a fresh job on that same role, so the ruler stays put. How the cut itself works will not rescue a row that has no score. Moving 60 to 40 does nothing for a parse failure.

Do not “fix” a failure by renaming the file to the student’s real name and uploading again unchanged. The name on a failed row is not the bug. The missing text is the bug. A prettier filename will still fail, and you will now have a second placeholder.

How HireQwik tells a duplicate file from a second person

Hash skip means the bytes matched. It does not mean we understood the person. Two students will not share a hash unless one copied the other’s file exactly. If you see one row and you expected two, open the file you kept and confirm whose name was parsed into it.

The opposite case is more common. The same student submits a morning CV and an evening CV. The bytes differ, so both rows exist. After parsing, you may see the same email twice, with two scores. HireQwik does not merge those at upload. You decide which score belongs in the conversation. I keep the higher score only after I confirm both files are the same person and the higher one is the more complete CV. An inflated second file full of pasted keywords should not win on autopilot. Why keyword match is not fit is the reason I read both.

A HireQwik checklist before the shortlist is final

I use this order. It is dull, and it prevents the email that says a strong student was “rejected by AI.”

1. Compare files selected with candidates created. The gap is rejected types, oversized files, or hash skips.
2. Open every parse-failed row. Read the summary. Do not assign a score in your head.
3. Spot-check five successful names against the PDF. If the parsed name is a section heading like “Curriculum Vitae,” the text layer is messy and the batch needs a closer sample.
4. Only then filter to shortlisted and talk about who cleared the cut.

Step 3 is the uncomfortable one. A file can clear the 50-character bar and still parse a heading as a name. The email may still be right. Look. The match against the job description assumes the document is the candidate’s history, not a template with the name in a text box the extractor missed.

The Ladders eye-tracking write-up on HR Dive is about human glances. A parse failure is the machine version of not glancing at all. Publishing a shortlist that silently omits those files is worse than a seven-second glance, because the omission looks like a decision. SHRM’s 2026 finding that many HR teams are using AI without a sturdy policy is relevant here in one practical way: your policy can be a sentence. Unread files are reported back. They are not treated as No.

If the folder was meant for a campus morning, send the failure list the night before, not after the panels start. The sequence is in the campus shortlist from PDF files. If you are unsure you should have used files at all, the fork with Excel is in picking a file drop or a spreadsheet.

Three files in one HireQwik folder, three fates

I keep a tiny example so someone opening this screen for the first time can learn the statuses without a 200-file pile. Imagine three documents dropped together for one backend role.

The first is a normal text PDF, two pages, email in the header. It becomes a person. The placeholder filename disappears. A score between 0 and 100 appears. Whether that person is on the shortlist depends only on the cut.

The second is a phone photo saved as PDF. The page looks full. The text layer is almost empty. The row stays, the filename stays, the status is parse failed, and the summary says the text could not be extracted. There is no number to argue with.

The third is a copy of the first PDF, saved again from the same download. The bytes match, so it never becomes a row. Your count of files is three. Your count of candidates is two. That gap is not a missing student. It is a duplicate of the first file.

If you only open the shortlist filter, you might see one name and assume the other two were rejected for fit. They were not. One was unread. One was a twin. Write that down before you tell a manager the AI “kept the best.”

How I sort a bad HireQwik folder before I answer anyone

A messy upload produces three piles, and I reply to each pile with a different sentence. Mixing the sentences is how a student hears “you were rejected” when the file was never read.

Pile one never became a row. The extension was wrong, one document was too heavy, the whole drop was too heavy, or there were too many documents for one job. These people are not in the review table at all. I count them from the upload message, not from the shortlist filter. The reply is mechanical: send a PDF or DOCX, keep each document under the per-file cap, and split the drop if the pile is huge. I do not apologize for a score. There was no score.

Pile two became a row and then stopped. The label is still the filename. The address is blank. The status says the read failed, and a short summary sits on the row so you are not staring at an empty error. This is the photo, the scan, the one-line file that only says the CV is available on request. The reply names the file and asks for a text PDF or a Word file. I attach nothing about the cut. Mentioning 60 here teaches the sender the wrong lesson, that a low number caused the miss.

Pile three became a person and a number, and then missed the cut, or cleared it. That pile is a judgment. The reply, if you send one, can mention the role and that the history did not match it. It should not be copied onto pile two. I have seen a template that says “your profile did not meet the score” go out to unread scans. That template is a lie. Unread is not a profile.

When the replacements come back, I start a new job on the same role rather than pretending the old rows will wake up. The old failed rows stay as a record of what we could not read. The new files get their own pass. If I drop the replacement into a different job by mistake, the numbers will not be comparable and the panel will argue about two rulers. The role name shown above the table is the check. Read it before you press start.

I also keep a tally in the note: selected, rejected at the door, skipped as identical bytes, failed to read, scored. Those five counts should add up to the folder. If they do not, I am missing a pile and I do not send the shortlist yet. The arithmetic takes five minutes. The argument it prevents takes an afternoon.

One more habit. I open the failed summary before I invent a cause. The summary is there so you do not guess “corrupt” when the text was simply too thin, or guess “too thin” when the type was refused before a row existed. Guessing feels faster. It sends the wrong ask back to the candidate, and the second file fails the same way.

Sort the piles, send the matching sentence, rerun only the replacements on the same role, and check that the five counts add up. That is the whole recovery. It is slower than hiding the failures inside the shortlist filter, and it is the only version you can defend.

Bring a batch that failed if you want another pair of eyes on it. We can read the error summaries with you and tell you which files to ask for again.