There is a difference between a process that looks polished and one that produces better hiring decisions. This guide focuses on the practical choices that hold up when the work is busy, the information is incomplete and somebody has to make a call.
Write for a human first, then make the structure obvious
A parser does not need marketing copy. It needs dependable labels and clean lists. Use familiar headings: About the role, Responsibilities, Requirements, Preferred qualifications, Compensation, Location and Hiring process. A candidate benefits from this too: they can see what is expected without translating brand language.
Put one requirement on each line
“Python, SQL, stakeholder management and a growth mindset” is hard to interpret and impossible to score fairly. Write atomic requirements instead: “Three or more years building production Python services”; “Can write and review SQL queries”; “Has partnered with non-technical stakeholders.” Each line has a subject, a level and a reason it matters.
Separate required from preferred
Blending them inflates the apparent bar and produces bad matching. Requirements should be the conditions for doing the job safely on day one. Preferred qualifications are advantages, not hidden vetoes. If a requirement is genuinely flexible, say so plainly. Candidates should not have to guess which phrase carries weight.
Name the work, not just the tools
Tools age quickly. Outcomes travel. Pair each technology with the decision or result it supports: “Operate Python services that process payroll events” is richer than “Python expertise.” It gives candidates a way to assess fit and lets a matcher find evidence beyond an exact keyword.
Do not bury practical constraints
State compensation, employment type, location, work-authorisation requirements and expected working pattern in their own labelled lines. These are not footnotes; they decide whether a conversation is viable. A clear range also reduces time spent screening people who could never accept the offer.
Paste a draft into the job parser and inspect the structured requirements before you post it.
The short version
- Write for a human first, then make the structure obvious. Make the choice explicit, then test it against the work rather than a hunch.
- Put one requirement on each line. Make the choice explicit, then test it against the work rather than a hunch.
- Separate required from preferred. Make the choice explicit, then test it against the work rather than a hunch.
- Name the work, not just the tools. Make the choice explicit, then test it against the work rather than a hunch.