Screen Applicants Against a Job Description

Use this Official Skill as starting guidance for a first or redesigned applicant-screening workflow. If the user already has a tailored screening skill, follow that instead.

Context, setup, and planning

Try to understand how the user wants applicants assessed before reviewing the full pool. Approved job descriptions, scorecards, hiring documentation, ATS history, prior screening notes, and examples of strong or rejected candidates can help when they are available. They are not prerequisites. Relevant context may include:

• where the applications live and where the result should go;
• the role, responsibilities, and evidence of success;
• three or four important requirements or dealbreakers;
• hard criteria such as location, compensation band, must-have skills, and eligibility;
• softer signals such as seniority, hypergrowth experience, technical background, or communication evidence;
• the fields, rating scale, explanation depth, and caveats the user wants to review;
• whether the user wants a quick screen of the full pool or deeper research on the strongest applicants.

The user owns the hiring criteria. Draw them out explicitly instead of silently turning a vague brief into a rigid rubric. Examples can calibrate the review without turning one person's biography into the requirement. Never use protected or irrelevant personal characteristics as screening criteria.

When the hiring bar is not already clear, offer to review a small, varied sample first, explain the fit reasoning, and adjust the rubric from the user's reaction before screening the full pool. If the sample reveals that the rubric or available evidence is not usable, stop and clarify rather than scaling a weak review.

Present a concise plan covering the rubric, screening depth, calibration method, intended deliverable, destination, and review point. Let the user confirm or adjust it before reviewing the full pool.

Execution

1. Turn the accepted requirements into a concise, job-related rubric. Keep hard requirements distinct from softer signals so the user can correct either.
2. For a large pool, extract the requested fields and inexpensive signals once, narrow the pool, then spend deeper review or research on the remaining subset. Uniform deep enrichment across every applicant is usually wasteful.
3. Compare each applicant against the agreed criteria using evidence from their application and other approved professional sources. Do not over-index on exact job titles when the evidence shows transferable experience.
4. Keep observed evidence separate from inference. Flag missing information, ambiguity, identity uncertainty, or thin evidence instead of inventing background, experience, or fit.
5. If calibration is part of the plan, show the initial sample with the reasoning, incorporate the user's corrections, and apply the sharper rubric to the remaining applicants.
6. Before presenting, check for duplicates, possible identity mismatches, and current pipeline state in the approved ATS or tracker when available.
7. Rank the shortlist using the agreed scale. For each applicant, show the overall assessment, evidence against the important criteria, a short fit summary, and any caveats.
8. Report how many applicants were reviewed and how the pool was narrowed. Especially on an early run, include a few applicants set aside and why so the user can calibrate the judgment.
9. Keep the result reviewable. Do not reject applicants, change ATS records, send messages, or take other external actions without the user's approval.

Useful sources

These sources may help when connected and approved; none is automatically required:

• Google Drive
• Gmail
• Outlook

Suggested outcome

Produce the agreed applicant-screening result in the requested destination and format. It may be a shortlist, ATS review, spreadsheet, table, document, or another artifact. Include the requested fields, verifiable application or profile links when available, an overall assessment, per-criterion evidence, caveats, uncertainty, and reviewed and filtered counts.

Suggested next steps

• If the applicant pool does not contain enough strong matches and the user wants to search beyond it, use strawberry/recruiting/source-candidates.
• If a team should reuse the accepted rubric, fields, and review process, use strawberry/operations/set-up-shared-team-workflow.
• After review, offer to save the accepted rubric, screening depth, fields, rating scale, destination, and review process as a user-owned screening skill.