build.allanninal.dev

Part 5 of 7 · Applicant screener series ~5 min read

How a hiring decision gets made

A card sits at the top of the hiring manager’s queue. It shows the role, the label the screener landed on, the must-haves met with their quoted lines, the gaps, and the full resume. There are three buttons: advance, hold, and pass. What happens when the manager taps one? The honest answer is that the system does the bookkeeping — but the decision is entirely the person’s. This post walks through the three actions, how each is logged, and how a human can overturn any label the screener produced.

Key takeaways

  • Three actions per card: advance (move to interview), hold (park for later), pass (turn down, with a reason).
  • Every action is the human’s. The screener does no advancing, holding, or passing on its own.
  • A manager can open a parked “no” and advance it — the screener’s label is a suggestion, not a gate.
  • Pass asks for a short, job-related reason, so a turn-down is never a silent or unexplained one.
  • Every action writes an audit row with the user, the time, the label before, and the action taken.

Three actions on a card

Three actions on a candidate card A diagram showing one input on the left flowing into a candidate card, then branching into three action paths the human can take. Far left: a "Candidate card" box showing the role, the label, the met must-haves with quotes, the gaps, and the resume, with three button placeholders below: Advance, Hold, Pass. The hiring manager taps one. The middle column shows the three branches. Branch one, Advance: a Function URL Lambda marks the candidate as moving to interview, writes an advanced row to the audit trail, and optionally drafts a friendly invite for the manager to review and send — never auto-sent. Branch two, Hold: parks the candidate for later in a held list; nothing is sent; the card can be reopened any time. The screener's label is not changed. Branch three, Pass: opens a small box asking for a short, job-related reason; on save, the Function URL Lambda records the pass with that reason, writes a passed row to the audit trail, and drafts a courteous decline for the manager to review and send — again never auto-sent. The right side shows the convergence: every action writes a row to the audit table with timestamp, applicant id, action, by-user, the label before, and notes. A note at the bottom: the screener's label is a suggestion — a human can advance a parked no, and every override is logged. Candidate card label, reasons, resume [Advance] [Hold] [Pass] Action 1 Advance • Mark as moving to interview • Invite drafted for review • Never auto-sent Action 2 Hold • Park for later in a held list • Nothing sent; card can be reopened Action 3 Pass • Asks a short, job- related reason • Decline drafted for review — never auto-sent Audit trail DynamoDB as-audit timestamp · applicant action · by-user label before · notes The screener’s label is a suggestion — a human can advance a parked no, and every override is logged.
Fig 5. Three actions per card, three different effects. Advance moves the candidate to interview. Hold parks them for later. Pass turns them down with a job-related reason. Every action is the human’s, and every action writes to the audit trail.

Action 1: advance (move to interview)

The manager reads the card, agrees the candidate is worth a conversation, and taps Advance. The button submits to a Function URL Lambda. The candidate is marked as moving to interview, and an advanced row is written to the audit trail with the manager’s name, the time, and the label the screener had landed on. Optionally, the system drafts a friendly interview invite — pre-filled with the role and a couple of time slots — and shows it to the manager to edit and send. The draft is never sent on its own; a human reads it and presses send.

That “never auto-sent” rule holds for everything that leaves the building. The screener can prepare a message to save typing, but a person always chooses to send it. Reaching out to a candidate is a relationship, and the system doesn’t get to start one by itself.

Action 2: hold (park for later)

Plenty of candidates are neither an obvious yes nor an obvious no. The manager isn’t ready to interview them but doesn’t want to turn them down — maybe they’re a strong maybe to revisit after the first round of interviews, maybe the role might split into two. Hold parks the candidate in a held list. Nothing is sent. The screener’s label isn’t changed. The card can be reopened any time and acted on later.

Hold exists so the manager never feels forced into advance-or-reject on a candidate they’re genuinely unsure about. A held candidate is a deliberate “not yet,” recorded as such, rather than a card that quietly falls off the bottom of the queue.

Action 3: pass (turn down, with a reason)

Sometimes the answer is no, and a human decides it. Pass opens a small box asking for a short, job-related reason — “doesn’t meet the required license,” “not enough hands-on experience for this level,” “role needs on-site, candidate is remote-only.” On save, the Function URL Lambda records the pass with that reason and writes a passed row to the audit trail. As with advance, it can draft a courteous decline message for the manager to review and send — never auto-sent.

Asking for a reason isn’t bureaucracy. It does two things. It nudges the manager to base the turn-down on the job, not a hunch — if you can’t name a job-related reason, that’s worth noticing. And it gives the audit trail something real: months later, “why did we pass on this person” has a plain answer tied to the role, not a blank. A pass is still always a person’s decision; the screener only ever suggested a label.

Overturning a screener label

The screener’s yes/maybe/no is a starting point, not a verdict. A parked no is not a closed door — the manager can open the reviewable list, read a candidate the screener scored low, and advance them anyway. Maybe the resume understated the experience. Maybe a must-have was met in a way the reader didn’t catch. Whatever the reason, the human wins. When a manager advances a candidate the screener marked no (or passes one it marked yes), that override is written to the audit trail as exactly that: a human overriding the suggestion.

Those override rows are worth watching. If managers routinely advance candidates the screener said no to, the rubric’s must-haves or pass marks are probably wrong — too strict, or missing a way people phrase real experience. The override log is how you learn that and fix the doc, instead of trusting a cut-off that’s quietly screening out good people.

Every action is logged, every action is reversible

The audit table records every advance, hold, and pass with the user who acted, the time, the screener’s label at the moment of the action, and the reason where one was given. If a card is acted on by mistake, it can be reopened and re-decided, and that correction is itself an audit row. The trail is the memory of the hiring round: who decided what, on what job-related grounds, and when. That’s exactly what you want to be able to show if anyone ever asks how a role was filled fairly.

Next post: the cost breakdown. The whole pipeline above runs in coffee-money territory at small-business volume; Part 6 explains exactly where the dollars go and why one model read per application keeps it cheap.

All posts