Job Analysis for Recruiters: Build Screening Criteria

Job analysis gives a recruiter a grounded working answer to a practical question: what does this role actually require someone to do? Before a hiring team writes a polished description, chooses screening criteria, or asks interview questions, it needs a source record that separates observable work from inherited preferences.

The U.S. Office of Personnel Management's job-analysis guidance describes the practice through tasks, competencies, and the connection between them. It says job-analysis data can establish required competencies, identify how tasks and competencies relate to the job, and inform job requirements and selection decisions. This article uses that narrow recruiting scope and does not attempt to cover every organizational use of job analysis.

The O*NET Content Model provides another useful reference structure. It separates information about the worker, including skills and knowledge, from information about the job, including tasks, work activities, and work context. O*NET can serve as an occupational reference point; the hiring team still needs to verify what is current and important in its own role.

Define the decision the analysis must support

Start by naming the role, the active requisition, the reason for the analysis, and the downstream decision it will support. A newly created position may require broad discovery. An established role may need a narrower update because its tools, scope, or outputs changed. A recruiter preparing a search usually needs enough detail to write the role accurately, define screening criteria, and design later assessment.

Give the analysis one owner and one current version. Record contributors, source dates, open questions, and the event that will mark the record ready for intake. Without that boundary, a job-analysis meeting can become an unstructured discussion about the ideal candidate rather than an examination of the work.

Collect evidence about the work, not the incumbent

Use several relevant sources where possible: the hiring manager, people who perform or supervise the work, current process documents, representative work products, system records, and a current occupational reference such as O*NET. Each source sees a different part of the role. The manager may know expected outcomes; an experienced role holder may know the recurring tasks and exceptions; a work product may reveal the actual level of judgment.

Keep each claim attached to its source. If one contributor says stakeholder presentation is central and another says it happens only occasionally, record the disagreement. Ask which outputs require that activity, how often it occurs, and what happens when it is done poorly. Do not settle the question by copying the current employee's background into the requirements.

A useful evidence log includes:

• Source: person, document, work sample, system, or occupational reference.
• Observation: the task, output, tool, decision, or work condition described.
• Scope: when the observation applies and which version of the role it describes.
• Confidence: confirmed, disputed, or awaiting verification.
• Owner: the person responsible for resolving an open point.

Write task statements that can be examined

Turn source notes into task statements before listing candidate attributes. Each statement should name an action, its object, and the intended output or context. “Communicates well” is not a task. “Presents a weekly delivery-risk summary to project owners and records agreed actions” identifies work that the team can discuss and later examine.

Keep broad responsibilities separate from their component tasks. “Owns account reporting” may include validating source data, investigating changes, drafting a summary, presenting findings, and recording follow-up actions. The component level makes it easier to decide which competencies matter, what evidence could demonstrate them, and whether two requirements are actually duplicates.

For each task, capture importance, expected level, recurrence pattern, consequence of weak execution, tools or information used, and whether the work can reasonably be learned after entry. Use rating anchors that describe observable differences. A label such as “high importance” is useful only when contributors share what that label means.

Link every competency to work

Once tasks are stable, identify the knowledge and skills needed to perform them. Build the linkage in both directions: every important task should have the necessary competencies, and every competency used in screening should point back to one or more important tasks.

This linkage exposes decorative requirements. If “executive presence” cannot be translated into observable work and a clear evidence request, it is not ready to become a screening criterion. If a task requires interpreting a particular data model, the team can name the knowledge needed, the level expected at entry, and the evidence that would support or weaken that conclusion.

Use a compact table with these fields:

• task ID and task statement;
• task importance and expected level;
• linked knowledge or skill;
• needed at entry or learnable after entry;
• acceptable evidence source;
• screen, interview, or work-sample stage; and
• review owner.

Do not treat the table as an automatic rejection engine. It is a shared definition for human review. Recruiters and hiring managers still decide how much evidence is sufficient, how to handle adjacent experience, and when an unresolved point should move to an interview question.

Separate entry requirements from development

A task can be important without every related competency being necessary on the first day. Ask what a capable new hire must already demonstrate, what can be learned with the team's normal support, and what evidence would distinguish the two. This prevents a long list of current-team knowledge from becoming a gate for candidates.

Classify each criterion as necessary at entry, useful at entry, or expected to develop. Then name the evidence source. Prior delivery of a similar output may support an entry requirement. Exposure to a related system may support a learnable criterion without proving mastery. Silence in a resume is an unresolved evidence state, not proof that the candidate lacks the capability.

Turn the analysis into recruiting artifacts

The completed analysis should feed several records without making them identical. Use the recruiting intake to confirm priorities, owners, and unresolved tradeoffs with the hiring manager. The analysis supplies task evidence; intake turns that evidence into an agreed search plan.

The candidate-facing description should summarize the role's purpose, meaningful responsibilities, and necessary qualifications. Run that draft through the Job Description Health Checker to identify wording and requirement-bloat signals that deserve a human edit. Keep source notes, task ratings, and internal disagreements in the analysis record rather than publishing them.

For screening, convert the task-to-competency table into a short criterion set. The guide to screening candidates against a job description shows how to connect each rating to visible resume evidence and route unknowns into later review. Use the same criterion IDs across the screen, interview plan, feedback form, and debrief so the evidence chain remains understandable.

Version the role when the work changes

Job analysis is not a one-time document. Set a review trigger based on the role: a material scope change, a new core system, a reorganized team, repeated disagreement during hiring, or a planned new search. Preserve the prior version, the change reason, contributors, approval date, and the recruiting artifacts affected.

When criteria change during an active search, do not silently overwrite the screen. Name the effective version and decide whether previously reviewed candidates need another look. A person should approve that decision and record why the change matters.

Use AI to organize evidence, not define the role

AI can group similar task statements, identify apparently unsupported competencies, compare versions, and draft a linkage table from verified notes. It can also flag criteria that lack an evidence source or appear in the job description without a task connection.

Every suggestion remains provisional. The model does not observe the work, know which source is authoritative, or own the hiring decision. A recruiter and hiring manager should verify task language, competency links, rating anchors, and downstream criteria against current source material. AI should not invent a requirement, resolve contributor disagreement, or decide whether a candidate advances.

Job analysis checklist for recruiters

• Is the role, requisition, purpose, owner, and current version clear?
• Does every material claim retain a relevant source?
• Are task statements observable rather than personality labels?
• Are broad responsibilities broken into examinable work?
• Does every screening competency link to an important task?
• Are entry requirements separated from learnable capabilities?
• Does each criterion name acceptable evidence and a review stage?
• Are disagreements visible with an owner and next step?
• Do intake, description, screen, and interview records use the same criterion IDs?
• Is silence in candidate material treated as unknown rather than negative evidence?
• Are role changes versioned and reviewed during an active search?
• Does a person own every role-definition and candidate decision?

Build the evidence chain before screening

Job analysis is valuable when it turns scattered beliefs about a role into a source-linked account of the work. Start with tasks, connect them to necessary competencies, distinguish what must be present at entry, and define what evidence the hiring team will review. The result is not an automatic decision. It is the shared foundation that lets recruiters write, screen, interview, and debrief against the same current definition.