Screen applications against the real requirements

Screening is where hiring quietly goes wrong. Not because people are careless, but because two hundred applications get read by a tired person against requirements that were never written down precisely, and the ones read on Friday afternoon are judged differently from the ones read on Monday.

Consistency is the thing worth automating here. Not the decision.

Write the requirements down properly

This is the whole playbook, and it happens before you touch Tenfold.

Open Documents and write one document per role. For each requirement, say whether it is a hard requirement or a preference, and say what evidence would satisfy it.

"Five years of experience" is not a requirement, it is a proxy. "Has shipped and maintained a production service they were on call for" is a requirement, and it is one an application can actually demonstrate.

If you cannot write down what would satisfy a requirement, an application cannot demonstrate it and you were never really screening for it. Most of the value of this exercise arrives before any application is read.

Have it score, with reasoning, against your list

Point an employee at the requirements document and a batch of applications.

Score each application against the requirements in the Senior Engineer
requirements document.

For each hard requirement, say Met, Not met, or Unclear, and quote the
part of the application that supports your judgement. If nothing in the
application speaks to it, say Unclear rather than Not met. Those are
different and we treat them differently.

Then give an overall recommendation of Advance, Reject, or Needs a human,
and one sentence of reasoning.

Do not consider anything not in the requirements document. Do not
comment on the candidate's name, where they studied, career gaps, or
how long they stayed anywhere.

The Unclear-versus-Not-met distinction is the important one. Applications are badly written all the time by people who would do the job well, and collapsing "did not mention it" into "cannot do it" is how you reject good candidates for being bad at applications.

Read the reasoning, not the score

The quotes are the output. The score is a sorting aid.

Spot-check by reading five applications yourself, forming a view, and then reading what it said. Where you disagree, ask which requirement produced the disagreement. Nine times out of ten your requirements document was imprecise, and you can fix that in one place for every application.

Answer candidates while they still care

The employee has its own email address, so it can answer questions about the role, the process and the timeline immediately instead of three days later.

Hold rejections for approval. There is no version of this where a rejection should send without a human seeing it, and the drafting is the tedious part anyway.

Draft a rejection for this candidate. Reference something specific and
real from their application. Do not tell them to apply again unless
there is an actual reason to think a future role would fit. Do not
explain the decision in a way that invites a debate about it.

Hold it for my approval.

What good looks like

Every application is judged against the same written standard, you can see the evidence behind every judgement, and the ones you disagree with teach you something about your requirements document.

What this does not do is decide. Advance, Reject and Needs a human are recommendations, and the third one exists because it should be used often.

Also covers

Answering candidate questions instantly. The recruiting employee has its own email address, so the questions that usually wait three days for someone with time get answered in minutes.

Answer candidate questions about the role, the process and the timeline
using our hiring documents.

Say what stage they are at and what happens next, if we have recorded it.

Never discuss their chances, never compare them to other candidates, and
never commit to a decision date we have not published. If they ask how they
did, say a human will be in touch.

The restrictions are the whole design. Speed is the benefit; opinions about a candidate's prospects are not something to hand to anything answering automatically.

Rejection notes that do not read like a machine. These should be drafted and held, always.

Draft a rejection for this candidate. Reference something specific and real
from their application.

Do not explain the decision in a way that invites a debate about it. Do not
say we will keep them on file unless we actually will. Do not tell them to
apply again unless there is a real reason to think a future role would fit.

Hold for my approval.

The instruction about keeping them on file is a small honesty that candidates notice. Everyone has been told it and nobody has ever heard back, so it now reads as the standard way of saying nothing.

Read every one before it goes. A rejection is the last thing most candidates will ever receive from you, and it is the one they talk about.