Writing job descriptions for AI screening

Why the job description matters more now

Most job descriptions are written to attract applicants and get past legal review. They list a dozen requirements, half of them boilerplate, and a paragraph about culture. People reading them fill in the gaps from experience.

A model reading them does not. Infyva generates role-specific questions from the job description, with each question aimed at a different skill or competency it mentions. If the description says "excellent communication skills" and nothing else about how the person communicates, you get a generic communication question. If it says "explains billing errors to small business owners by phone and email, and follows up within one business day", you get a question about exactly that.

Start with outcomes, not duties

Before writing anything, ask the hiring manager: what will this person have achieved in their first six months if they are good? The answers are your raw material.

• Weak: "Responsible for customer onboarding."
• Better: "Gets new customers live within two weeks of signing, running the setup call and fixing configuration issues without escalating to engineering."

The second version tells candidates what the job is, and tells the interview what to ask about: running a setup call, diagnosing configuration problems, judging when to escalate.

Name four to six competencies

From the outcomes, pick the four to six things that decide success. These should line up with the scorecard you will use, so the questions and the scoring point at the same targets. For each one, write a sentence that describes it in observable terms.

If you cannot describe what a good answer about a competency would sound like, leave it out. Our structured interviews guide covers how to turn these into rating anchors.

Give the real context

Good questions need specifics. Include the things a strong candidate would ask about anyway:

• Who they work with or serve: small business owners, hospital patients, enterprise IT buyers, warehouse teams.
• Channels and tools: phone, chat, email; the ticketing system, the CRM, the forklift class.
• Volume and pace: tickets per day, calls per week, deals per quarter, orders per shift.
• The hard parts: angry customers, night shifts, long sales cycles, legacy code.
• Working conditions: hours, shift patterns, travel, physical requirements.

Honest detail about the hard parts does two things: it produces better questions, and it lets people who would hate the job opt out before they interview.

Separate must-haves from nice-to-haves

Long requirement lists spread the interview thin. If you list ten skills, the questions will try to cover ten skills in a handful of answers, and none will be tested properly. Put the four to six real requirements first and label the rest clearly as a bonus. Credentials and hard requirements, such as a license or a right to work, are usually better checked with a yes or no screening question than in the interview.

What to leave out

• Coded language. Phrases like "digital native" or "young and energetic team" point at age. Describe the work instead.
• Requirements that are not real. A degree or "10+ years" that the job does not need narrows the pool and pushes questions toward credentials.
• Internal jargon. Team names and acronyms mean nothing to candidates and produce confusing questions.
• Boilerplate in the middle. Benefits and company history are fine, but keep them away from the requirements so they are not mistaken for skills to test.

A short example

Example, written for this guide
Customer Support Specialist, small business accounts. You will answer 40 to 60 phone and chat conversations a day from small business owners using our invoicing software. In your first six months, you will resolve most billing and setup questions on the first contact, explain fixes in plain language, and know when a problem needs to go to the product team. We are looking for someone who stays calm with frustrated customers and moves them to a clear next step; explains technical steps to people who are not technical; follows up on every promise within one business day; and writes notes the next person can act on. Shifts are 8 hours, Monday to Friday, with one Saturday a month.

From that description, Infyva would generate questions about calming a frustrated small business owner, explaining a setup fix, deciding when to escalate and tracking follow-ups, which is what you would want to ask anyway. See the customer support use case for example questions and scoring.

Before you publish

1. Could a stranger tell what a good first six months looks like?
2. Are there four to six competencies, each described in observable terms, matching your scorecard?
3. Does it name the customers, channels, tools, volume and hard parts?
4. Are nice-to-haves clearly labelled?
5. Have you removed coded language and requirements the job does not need?
6. Does it tell candidates there will be a recorded voice interview scored with AI and reviewed by a person? In New York City, a notice is required by law; see our Local Law 144 guide.

Then preview the questions Infyva generates. If they feel generic, the description usually is too. Edit it, or on Pro and Enterprise build a fixed question bank for the job.