How an AI recruiter runs a hiring pipeline from role to shortlist

To keep things concrete, we will track one opening the whole way through: a Senior Backend Engineer, fully remote within the United States, with a base salary band of 160,000 to 190,000 USD. The team runs a Python and PostgreSQL stack on a large cloud platform, ships an API used by mid market finance teams and wants someone who has owned a production service end to end, including on call. They hire maybe ten engineers a year, so they cannot justify a full time technical recruiter, and an agency fee on a role at this level would commonly land somewhere between 24,000 and 47,500 USD.

Every number you see in the funnel below is an illustration of a typical example run, not a measured average and not a promise. Real results move with the market, the salary band, how niche the stack is and how quickly the hiring manager responds. The value of the example is in the shape of the funnel and the decisions made at each stage, which stay remarkably similar from role to role.

Most failed searches fail at intake. A vague brief like "strong backend person, startup mindset" produces a vague search, and the recruiter only discovers the real requirements after the hiring manager rejects the first ten profiles. The intake step forces the important questions up front: title, location or remote policy, salary range, seniority, must haves, nice to haves and deal breakers. For our role, the hiring manager fills these in about ten minutes.

The distinction between the three requirement buckets matters more than any other field. A must have is something a candidate cannot succeed without. A nice to have tips the scale between two good people. A deal breaker removes someone regardless of everything else, and it should be rare, legal and job related. Writing them down separately is what lets the later scoring step behave like a careful recruiter instead of a keyword filter.

From the intake, the system drafts two artifacts. The first is a job description that is honest about the work, includes the salary range (several US states and cities now require pay ranges in postings, and candidates respond better to them anyway) and becomes the hosted apply page for inbound applicants. The second, and more important, is a scoring rubric: a list of weighted criteria with a plain language description of what evidence counts for each one.

The hiring manager edits both before anything goes out. In our example, she raises the weight on production ownership because the last two hires struggled on call, and she removes a criterion about a specific web framework because, on reflection, any competent Python engineer learns it in a week. This is the moment that shapes the entire search, so it deserves a careful fifteen minutes. If you want a deeper treatment of how to write these criteria, we cover it in our guide to scoring rubrics for resume screening.

Sourcing pulls from three places at once. The first is public professional profiles and open web sources, processed under a documented legitimate interest basis with a logged source for every person found. The second is the company's own talent database, imported through CSV or from an ATS such as Greenhouse, Lever or Workable, which often hides strong people who applied for a different role a year ago. The third is inbound applicants arriving through the hosted apply page.

For the backend role, the search casts a deliberately wide net based on titles, skills, seniority signals and location, and in our example run it surfaces about 500 people. That number is meant to be large. It is cheaper to read 500 profiles carefully and discard most of them than to search narrowly and miss the engineer whose title says "Platform Developer" but whose work history is a perfect match. This is where automated candidate sourcing earns its keep, because no human team reads 500 profiles with equal attention.

Each of the 500 profiles is analyzed against the rubric, criterion by criterion. Instead of a single opaque match percentage, the recruiter sees a score per criterion and a short reason that points to the evidence, for example "Led migration of billing service to event driven design, 2022 to 2024, owned on call rotation" next to the production ownership criterion. When there is no evidence, the reason says so, which is just as useful.

In the example, roughly 80 candidates clear the bar and move to outreach. The recruiter can open any profile below the line and override the decision, and can adjust a weight and rescore the pool in seconds if the results look off. A common pattern is that the first ten results reveal a rubric problem, such as overweighting a nice to have, and a single edit fixes the entire ranking. Treat that first look as calibration, not as the final answer.

Outreach is where automated recruiting most often goes wrong, so the guardrails are strict. Messages go out as a personalized multi step email sequence from the customer's own connected mailbox in Gmail or Outlook and Microsoft 365, not from a shared bulk sender. Each first message references something specific and true about the candidate's background, states the salary band and remote policy, and explains in one line why the role might be worth their time.

Daily sending caps protect the mailbox's reputation, and messages only go out between 8:00 and 20:00 in the recipient's local time. Every message includes an Article 14 GDPR notice where it applies and a one click opt out, and anyone who opts out lands on a workspace wide suppression list so no other role contacts them again. In our example, the 80 selected engineers receive a three step sequence spread over about ten days, with follow ups that add new information rather than simply bumping the thread.

In the example run, about 25 of the 80 candidates reply. Each reply is classified as interested, not now, not interested or question. An interested reply sends the screening questions next. A "not now" gets a courteous acknowledgment and a note on the profile so the next search can revisit them later. A "not interested" closes the conversation cleanly. Questions get an answer drafted strictly from the role's facts, such as the band, the stack, the on call setup or the interview steps.

The rule is that the system never invents an answer. If a candidate asks something the role facts do not cover, such as equity details that were not provided, the conversation is flagged for a person. The recruiter or hiring manager can also take over any thread at any moment, and from then on the human owns that conversation. Senior engineers can tell instantly when a reply dodges the question, so this boundary matters for your employer brand as much as for accuracy.

Interested candidates receive a handful of knockout and pre screening questions. For our role, they confirm US work authorization, comfort with the salary range and willingness to join an on call rotation, and they describe in two or three sentences a production incident they handled. Knockout answers catch mismatches that would otherwise surface in a frustrating first interview, and the open answer gives the hiring manager a quick read on how the candidate thinks.

Next comes a short, role specific skills test with multiple choice and short answer items, scored automatically. For a senior backend engineer, a good test takes twenty to thirty minutes and covers reading a slow SQL query plan, reasoning about idempotency in a payment webhook and spotting a race condition in a short snippet. Respect for the candidate's time is not optional at this level: a four hour take home exercise at the screening stage loses exactly the people you want most. This combination of questions and testing is the core of AI candidate screening.

Candidates who pass screening pick an interview slot directly from the hiring manager's connected Google Calendar or Microsoft 365 calendar. No back and forth emails, no time zone arithmetic across a remote US team spanning four zones. Reminders go to both sides automatically, and if the hiring manager blocks out an afternoon, the offered slots update without anyone touching the process.

Scheduling sounds trivial, but it is often where pipelines silently stall. A strong candidate who waits four days for a reply about availability is frequently in final rounds somewhere else by the time a slot is confirmed. Letting candidates book within minutes of passing a screen is one of the least glamorous and most effective changes a hiring team can make.

The output is a ranked shortlist, in our example five candidates. Each card shows the overall score, the per criterion breakdown with evidence, screening answers and skills test results. The hiring manager opens it through a shareable link and clicks approve or reject on each person. Nothing advances or gets rejected automatically at this point: a human approves every shortlist, and there are no automated final decisions about anyone.

That design choice is about more than legal caution, though it also keeps you on the right side of rules about automated decision making. Shortlists that carry evidence get better feedback. When a hiring manager rejects someone, the reason usually maps to a specific criterion, and that feedback improves the rubric for the next role. Over a few searches, the rubric becomes a written record of what the team actually values, which is something most companies never manage to produce.

The pipeline does not end at the shortlist. Candidates who were not selected receive a respectful rejection email instead of silence, and the hiring manager gets reminders when approvals or interview feedback are overdue. Sourced people who never replied are deleted automatically after 30 days by default, configurable between 30 and 180 days, and every candidate record can be exported or deleted in one click if someone asks.

Here is the full example funnel for the Senior Backend Engineer role. Read it as an illustration of a typical example run and not as a benchmark. If you want to see each stage in more detail, our page on how AI recruiting works walks through the same steps from the product side.