How to Build a Candidate Shortlist From Criteria When You Are the Whole Sourcing Team

A hiring manager sends you a brief. It says senior backend engineer, fintech, Berlin, and — the part that actually matters — "someone who has done this at our stage, not at a company with three hundred engineers". Your search tool can handle "Berlin". It cannot handle the rest. This article is about the rest.

Step 1: split the brief into two columns

Before opening any tool, write the brief out as two columns. This takes ten minutes and saves hours.

Hard constraints	Judgement criteria
Based in or able to work in Berlin	Has worked at an early-stage company, not only at large ones
Right to work in Germany	Has owned a system rather than contributed to one
Backend, not frontend	Has dealt with money movement or regulated data
Roughly 7+ years of experience	Has shipped without a platform team to lean on

The test for the left column is simple: if this is wrong, is it an automatic no? Location, work authorisation, a required certification. If the answer is "well, it depends", it belongs on the right.

Everything on the left becomes a filter. Nothing on the right does. That rule is the whole method, and breaking it is the most common way small teams end up with a search that returns nobody good.

Why the right column must not become a filter

Take "has worked at an early-stage company". You could filter for company size under 50. That removes the person who joined at 30 people and stayed until 400 — who is exactly the profile the hiring manager described, because they lived through the stage you are hiring for.

Or take "fintech experience". Filtering on the fintech industry tag removes the person who built payment infrastructure inside a marketplace company. Their profile does not say fintech. Their work was fintech.

Every judgement criterion you convert into a filter removes people like this, and you never see who they were. That is what makes the mistake so persistent — it produces no error message, just a quietly worse list.

Step 2: build a wide pool with the left column only

Run the search on hard constraints alone. It will return more people than you want. That is correct and expected.

Resist the urge to narrow. When a search returns 400 people instead of 40, the instinct is to add filters until the number looks manageable. What you have actually done is decide, blindly, which 360 people to never look at.

If 400 is genuinely too many to handle, tighten a hard constraint — a tighter experience band, a smaller radius — not a soft one. Tightening hard constraints removes people you were never going to hire. Tightening soft ones removes people you would have.

On titles specifically

Job titles are the most commonly used filter and among the least reliable. "Head of Engineering" at a 20-person company and at a 2,000-person company are different jobs. Meanwhile the person who did exactly your job might be titled Principal Engineer, Tech Lead, or Engineering Manager.

Use titles as one signal, and always include the adjacent ones. Our piece on what boolean search cannot express has concrete strings for this.

Step 3: read for evidence, not keywords

Now you have a wide pool and a right-hand column. This is the part that takes the time, so it is worth having a method.

For each judgement criterion, decide in advance what would count as evidence. Not what word you are looking for — what fact would convince you.

Criterion	Weak evidence	Strong evidence
Worked at early stage	Company described as a startup	Joined when the company was small and stayed while it grew
Owned a system	"Responsible for" in a bullet list	Named as the person who built or rebuilt a specific thing
Regulated or money-handling work	Worked at a bank	Describes payments, ledgers, compliance or audit work directly
Shipped without support structures	Small company	Did work that a platform team would normally do

With that table in front of you, three questions get you through most profiles in under a minute:

1. What did this person actually build or run? Not their title — the thing itself.
2. At what stage was the company when they were there? Check the dates against what you know of the company.
3. Is there anything here that rules them out? One clear disqualifier is enough to stop reading.

If a profile takes you four minutes, something upstream is wrong. Either your criteria are not written down clearly enough, or your search returned people so far off the brief that each one is an investigation. Both are worth fixing before you grind through another 300 profiles.

Step 4: record the rejections

This is the step everyone skips and the one that makes every future search better. When you reject someone, note the reason in three or four words. "No ownership evidence." "Only large companies." "Wrong domain."

Ten seconds each. After one role you will have a pattern, and the pattern tells you something you cannot learn any other way:

• Most rejections for the same reason? That criterion should be applied earlier, or your search is built around the wrong thing.
• Rejecting almost nobody? Your filters are too tight — you are only seeing the obvious matches and missing the pool around them.
• Rejecting almost everybody? Your search is not aimed at the brief at all.

Without rejection data every search looks equally good, because you only kept the people you liked.

Worked example, end to end

Same Berlin fintech role. Numbers here are one plausible run, not a benchmark — yours will differ.

Step	Count	Time
Write criteria in two columns	4 hard, 4 judgement	10 min
Search on hard constraints only	380 profiles	15 min
First pass — obvious no's, 20 seconds each	380 → 95	2 h
Second pass — read the 95 properly	95 → 24	1 h 20 m
Rank by fit, keep the top	24 → 16	20 min
Shortlist	16 worth contacting	~4 hours

Four hours to produce sixteen names. That is roughly what this costs when done properly by hand, and it is why the first instinct is always to narrow the search instead — narrowing feels like it saves the four hours. It does not. It just moves the cost somewhere you cannot see it, into the people you never reviewed.

Five mistakes that cost the most

1. Filtering on judgement criteria. Covered above, and worth repeating because it is by far the most expensive.
2. Searching before writing criteria. You end up matching whatever the results suggest rather than what the role needs.
3. Narrowing to make the number look nice. A manageable result count is not the same as a good one.
4. Contacting before finishing the review. Tempting when the first few look good. It produces replies from people who turn out not to fit, which costs a screening call each.
5. Keeping no record. Without rejections you cannot improve the next search, so every role starts from zero.

Making the review part cheaper

Nothing above requires special tooling — it is a process, and it works with whatever search you already have. But notice where the four hours went: almost all of it was reading profiles to apply the right-hand column.

That is the part worth attacking. If each profile arrives with the evidence for each criterion already pulled out and linked — the role, the dates, the sentence that supports or refutes it — the review becomes confirmation rather than investigation, and the four hours becomes closer to one.

Tools differ sharply in whether they do this or simply return more results faster. The distinction, and a short test that exposes it, is in our comparison of LinkedIn Recruiter alternatives for small teams.

That is what Hiris does: you give it both columns, and it returns the shortlist with the reasoning and proof links attached. The process in this article is the same either way. The difference is who does the reading.