68/100

Moderate evidence

ProblemPublished recordLaborProblem Space

The impact of algorithmic resume screening on applicants’ perceptions: the role of organisational dehumanisation

Truvace record
TRV-2026-2562raw data (JSON)
Version
v1Published
First published
Evidence type
Controlled or validated comparison
Sources
1 sourcePeer-reviewed
sha256
c5f5b513d6ce…check it

Purpose This paper aims to examine how algorithmic versus human resume screening shapes applicants’ perceptions of organisational dehumanisation (OD) and its consequences (i.e. intentions to pursue employment, organisational attractiveness and negative word-of-mouth). It explores one potential boundary condition of this relationship (i.e. negative attitudes towards artificial intelligence). Design/methodology/approach Three experimental studies were conducted on social media (Studies 1–2) and prolific academic (…

The problem

In three online experiments with 249, 210 and 392 participants, applicants whose resumes were screened by an algorithm rather than a person felt the employer treated them as less than human, and reported lower interest in the job, lower employer appeal and more negative word-of-mouth.

What this doesn’t fix

The moderating role of negative attitudes toward AI appeared in Study 2a but did not replicate in Study 2b, so that boundary condition remains unresolved.

Sources

1 on file
  1. Peer-reviewed2026-06-23

Cite this record

v1

Truvace Impact Record TRV-2026-2562, v1: “The impact of algorithmic resume screening on applicants’ perceptions: the role of organisational dehumanisation.” Truvace, 2026-11-12. /record/TRV-2026-2562 (accessed on the day you copy it). sha256 c5f5b513d6cef745…

Change history

1 version

Every change made to this record since it was first published, and why. Nothing has changed since it went up.

  1. Publishedv1c5f5b513d6ce…

    Certified into the record

Check this record hasn’t been altered

Check this record hasn’t been altered
How to check it yourself, without trusting this page

Download any version from /api/record/TRV-2026-2562 and hash its canonical field yourself, for example with shasum -a 256. You should get its content_hash. Each version’s text also ends with prev:and the hash of the version before it (version 1 points to 64 zeros). If anyone had changed a single character of any version after it was saved, those hashes wouldn’t line up.