How to Turn a Job Description Into a Sourced Candidate List

A recruiter we worked with pasted a job description into her sourcing tool and got back 701 people. By her own count, about 200 were worth opening, and the rest were noise she still had to scroll past. That is the quiet tax on how most teams source candidates from a job description today. The description goes in, a wall of half-relevant profiles comes out, and the real work of deciding who is worth a call has not begun.

It should run the other way. You should be able to source candidates from a job description and get back a short, ranked list you would be comfortable handing to the client. This guide walks the whole path, from a raw description to that list, and it is honest about the step where most tools quietly give up. We build this kind of workflow with recruiting teams for real, on top of live people data, and you can try the same thing on a free Crustdata account with 100 credits.

A job description is a wish list before it is a search

The first thing to know about a job description is that it is rarely an accurate spec. As one agency recruiter put it, a JD is often "a wish list of everything," written to impress the candidate and cover the hiring manager. Half of it is genuinely required and half is the thing someone would like in a perfect world.

So before any searching happens, the JD has to be read down to what actually disqualifies a candidate versus what is merely nice to have. That separation is the real input to sourcing. Get it wrong and every later step inherits the error, because you are now searching for a person who may not exist.

Why "paste the JD, get keywords" is where it breaks

The common advice is to feed the description to a tool that extracts keywords and builds a search string. It feels like automation. In practice it is the step that fails recruiters, because pulling nouns out of a JD is the one part of the job they could already do in their sleep.

The misses are specific. A keyword parser searching for an electrical engineer will skip the strong candidate who calls herself a hardware engineer, because the title does not match the word. Ask it about a cloud role and it can break "GCP" into three separate letters and hunt for G, C, and P. One recruiter described pasting a description into a tool and watching it spit back the obvious keywords, then said the quiet part out loud: "I could have done that myself." A string of keywords is a worse version of what is already in your head, and it carries all of the JD's wish-list noise straight into the results.

Keyword matching shares the JD's vocabulary. Real criteria share its job.

This is why the 700-result pile happens. The search matched words rather than people, so it returned everyone who shares vocabulary with the description and left you to sort out who shares the actual job.

Turn the description into real criteria

The fix is to translate the JD into criteria a search can act on. That means expanding the title into the ones people actually use, so a search for the robotics role reaches the hardware, embedded, and firmware engineers doing the same work under different labels. It means normalizing skills and companies so a candidate from a comparable background surfaces even when her wording differs from yours. We go deep on that translation in our guide to recruiting search normalization. The short version is that a query built this way asks who has done the job, and that is the only kind of result worth ranking.

Get the list ranked, and keep it steerable

A good search still returns more people than you want to read, so the list has to arrive ranked. Ranking is what lets you trust the top of the list and ignore the bottom, which is the only way the volume ever becomes workable.

Take the robotics search. The first pass returned around 700 names. Translated into real criteria and ranked, the same pool collapses to a few dozen worth genuine attention, and from there to a shortlist of about ten.

The search returns 700. The work is collapsing that to the ten worth a call.

An illustrative top of that list looks like this.

Compressing that ranked pool into the final shortlist is a craft of its own, and we walk through it in turning a raw pool into a working shortlist. The part specific to working from a JD is where it points your attention. The obvious top matches are obvious to every other agency too, so your time pays off most on the candidates the search is unsure about, where a real judgment call decides the fit.

What makes that possible from a JD is a ranking you can steer. You should be able to hand the search a few people you already know are good and have it re-sort around them, so the order reflects your read of the role rather than a score you have no reason to trust.

A match is not a list your client will accept

Here is the trap that catches even a well-ranked list. A high filter match is not the same as a candidate your client will accept. One recruiting team described running a clean search, shortlisting the matches, then watching the client reject them, because the filters were satisfied and the actual bar was not.

The way through is to treat the first list as a draft. You send a small ranked set, the client reacts, and that reaction tells you more than any match score could. The workflow has to let you fold it back in, adjust the criteria, and regenerate, rather than sending you back to scroll 200 profiles by hand. A pipeline that cannot take "more like this one, fewer like that one" and re-run is just a one-shot search wearing a nicer coat.

Add contacts and export the list

A ranked, calibrated list is still not the deliverable. The deliverable is a list someone can act on, which means contact details attached and the whole thing sitting wherever your team actually works.

This is the step the search-string tools never reach. They hand you a query to run somewhere else and call it done. Recruiters live with the consequence. As one agency founder put it, "I'm manually doing everything, so if it gave me 12 good results, I'm manually typing a message." The pipeline should close that gap, enriching each person on the shortlist with a way to reach them and exporting the set straight to your CRM or a sheet, so what reaches your pipeline is ready to work the moment it arrives. If you want to see that end state against one of your own roles, book a demo.

The whole thing as one pipeline

Put the steps together and the shape is simple. A job description goes in. A ranked, enriched candidate list comes out, with each row carrying a name, a current title and company, a profile, and a way to make contact. Because it runs on an API rather than a saved search, you can run the same role again next week and get the people who became a fit in the meantime, without rebuilding anything.

Underneath, the people data comes from Crustdata's people search API, which indexes public professional data across the open web rather than reading a single profile source. Coverage is strongest where people leave a public trail and thinner in pockets that do not, so it is worth testing against your own niche before you rely on it. The search itself, the part that turns a natural-language role into a structured query, is its own piece of work that we cover in building a candidate sourcing engine. What matters for the JD-to-list job is that the input is the description and the output is the list, with the translation, ranking, and enrichment handled in between.

Start with one open role

Time to introduction is the number that actually matters. One agency measures itself on whether it can find the right person within a few business days of a client asking, and everything above exists to protect that number. The faster a description becomes a short, trustworthy list, the more of the week goes to talking to people instead of sorting them.

So start with one open role. Take the description you are working right now, pull out what truly disqualifies a candidate, and run it as criteria rather than keywords. Look only at the ranked middle band, send a small set to the hiring manager, and fold their reaction back in. You can build the first version on a free Crustdata account, or book a demo to see it against one of your live roles. For more on the recruiting workflows this fits into, see our recruiting solutions.

Frequently asked questions

How do you source candidates from a job description without getting buried in results? Stop searching the words in the description and search the criteria behind it. Pull out what truly disqualifies a candidate, expand the titles to the ones people really use, and normalize skills and companies so equivalent backgrounds count as equivalent. A search built on criteria returns a rankable list instead of everyone who shares vocabulary with the JD.

Why does keyword or Boolean search from a JD miss good people? Because titles vary and keywords are literal. The strong candidate who calls herself a hardware engineer never shows up in a search for electrical engineer, and a parser can split a term like GCP into separate letters. Keyword matching finds shared words, and shared words rarely mean shared work.

How do you get from a long result set to a shortlist you can send the client? Rank the results so you can trust the top and ignore the bottom, then spend your judgment on the middle band where the real fit decisions live. Send a small ranked set as a draft, let the client react, and feed that reaction back into the criteria to regenerate rather than re-reading profiles by hand.

Is a high match score the same as a good candidate? No. A filter match means the criteria were satisfied, not that the client will accept the person. Treat the first list as a draft, calibrate it against people you already know are good, and adjust when the client pushes back.

What does the finished list include? A usable list is ranked, enriched with contact details, and exported to wherever your team works, so each row has a name, a current title and company, a profile, and a way to reach the person. The goal is a list you can act on rather than a search string to run somewhere else.