How to write an ICP that actually screens candidates
Most Ideal Candidate Profiles are glorified job descriptions. Here's the structure that turns an ICP into a working filter.
An Ideal Candidate Profile should do one job: take a pool of 10,000 candidates and return the 30 your hiring manager would actually want to interview. Almost none of the ICPs we see in the wild can do this — because they're written as prose, not as a decision structure.
The three layers every working ICP has
A working ICP isn't a bullet list. It's a three-layer filter.
Layer 1: Hard gates
These are binary disqualifiers. A candidate either has it or they don't. For a senior backend role at a fintech, hard gates might be:
- US work authorization (no sponsorship available)
- 5+ years in production-scale backend systems
- Experience with regulated financial data
Hard gates are few. Usually 2–4. If your hard gates list has 9 items, you've misclassified preferences as requirements and your funnel is dead on arrival.
Layer 2: Ranked preferences
This is where 90% of ICPs collapse. A preference is a tradeoff that the hiring manager can make but doesn't want to have to make every time. Examples:
- Fintech domain experience > generalist backend, unless the generalist comes from a top-10 engineering culture.
- "Shipped a zero-to-one product" outranks "shipped at scale," if the role is the first hire on a greenfield team.
- A candidate who self-taught and moved into a senior role is ranked equal to one with a CS degree from a top school.
The format matters: A > B, unless C. Without the tiebreaker clause, your AI screener — and your human recruiter — will guess. They'll guess wrong.
Layer 3: Signals and flags
Signals are directional features that don't decide by themselves but adjust ranking:
- Positive signals: open-source contributions in the domain, blog posts about hard problems, deep LinkedIn endorsements from respected engineers.
- Flags: gaps >12 months without explanation, five <18-month tenures in a row, a LinkedIn headline that reads like a personal brand manifesto.
The rule: signals never kill a candidate on their own. They bump the rationale that goes to the hiring manager.
The test: can a stranger screen with your ICP?
Hand your ICP to a smart person who doesn't know your company. Give them 50 candidate profiles. Can they produce a ranking your HM agrees with 80% of the time?
If no, your ICP is prose, not structure.
A working ICP is transferable. If only the recruiter who wrote it can use it, it's tribal knowledge — which is exactly the thing that breaks when the recruiter goes on leave or the HM rotates.
Why Jacinta makes this structural by default
Jacinta's intake extracts these three layers directly from the hiring manager in the first 20 minutes of a req opening. Not "describe your ideal candidate" — rather, a structured conversation: "If a candidate has X but not Y, what do you do? And if they have Y but not X?"
The output isn't a document. It's a ranked preference function that the sourcing, screening, and interview agents all read from.
The ICP as a shared artifact
Every step downstream of ICP capture — sourcing queries, screening rationales, interview question selection — is derived from the same structured ICP. No drift between what the HM said and what Jacinta filters on.
Common anti-patterns to avoid
- "Strong communicator" as a hard gate. It's not measurable on a resume. Move it to the interview rubric.
- "5+ years of X technology." Replace with "capable of leading a system design conversation in X" — which is what you actually want.
- Listing 15 nice-to-haves. If everything is a nice-to-have, the system can't rank. Cut to the 5 that matter.
- Using the job description as the ICP. JDs are for candidates; ICPs are for screeners. They are different documents with different audiences.
Curious how Jacinta turns a 20-minute HM intake into a working ICP? See it in action.
