How do you write a job posting?

A job posting is written for two readers at the same time. The first is the candidate: they read what the role is, where they will work and what is expected of them. The second is the evaluation itself: the requirement items you write on the posting are the input of scoring. The model invents no score; for every item it answers whether there is evidence in this CV and leaves a verbatim quote, and the arithmetic is done in code.

That is why writing a posting is not a question of style. The system sets four conditions, and all four decide either the record or its visibility: at least one requirement, weights coming to exactly 100, a body over 300 characters, and an active posting. Miss one and either the record does not save or the posting stays invisible in search.

The whole posting lives in one form, in six sections. The switch at the top of the form decides whether you write the posting by hand or have AI build it from a free brief. Whichever route you take, the last word is yours: the system never changes the status of an application on its own, AI suggests and your team decides.

• Basic Information: position, department, location, work mode, contract type, working hours, status and application deadline.
• Posting Description, Requirements and Weights, Responsibilities: the body the candidate reads and the input of scoring.
• Custom Application Fields and Scoring Bands: the questions specific to this posting and what each score range means.

In the panel go to Jobs, move to the Postings tab and open a new posting. The first section is Basic Information. The position title is not free text, it is picked from your company's internal position list; if the title you need is not on the list, you can create a new position without leaving the form. The moment you make that pick the department fills itself in and cannot be edited by hand, because the department belongs to the position.

The remaining fields set the frame of the posting. Location is free text and cannot be left empty. Work mode has three options: On site, Remote, Hybrid. Contract type has five options: Full Time, Part Time, Intern, Contract, Temporary. Working hours is picked from four preset ranges. Part of this set makes up the strip a candidate scans first, so it is a first impression rather than a matter of style.

The status field says whether the posting is live. The application deadline is optional: a posting left empty stays open until you close it, and the candidate screen reads "Open ended" instead of a date. If you do enter a date, the picker never opens a day before today; writing a past date on a posting whose status is Active gets the record rejected as well.

• The title has to be at least two characters and produces a unique address inside the company.
• Location, work mode, contract type and description cannot be left empty; working hours and the deadline are optional.
• A posting whose status is Passive or Closed stays in the panel and never appears on the public address.

The Posting Description is a single free text field and the body the candidate reads in the left column. What belongs here is the role itself: what the team does, which work this person takes over, what is expected in the first months. Introducing the company is the career page's job. Keep the description on the role and the candidate finds the answer they came for in the first paragraph.

Length is not a matter of taste here. One of the two gates that decide whether a posting reaches search results is body length, and the description is not the only thing counted: the description, the requirement items and the responsibility items are counted together, with whitespace collapsed before the characters are added up. The threshold is 300 characters.

The threshold was not set by guesswork. On 1 August 2026 the 13 active postings that were live were measured: the shortest body was 310 characters, the tenth percentile 363, the median 489, the longest 2002. Not one posting was under 300, so the threshold eliminates nothing that is live today and still refuses a body that was genuinely left empty. There is no upper limit; the median shows where a comfortably written posting lands.

The Requirements and Weights section is filled in item by item. Next to the text of each row sit two more controls: the percentage weight and the "Required" switch. The description the panel prints on the section already states the rule: write criteria that tell candidates apart and can be evaluated from a CV, and make the weights add up to 100.

The total rule is strict: at least one requirement is mandatory, every row has to carry a weight, and the total has to be exactly 100. Both 99 and 101 stop the record. The same rule is applied from a single schema on the save button and on the server, so a request that bypasses the browser stops at the same place. When you spread the weights, the practical route is to give most of them to the three or four items that genuinely tell candidates apart.

These items are not only for you: the candidate reads the same list item by item on the posting page, and the only thing they never see is the percentages. So the row you wrote for scoring becomes part of the text the candidate reads. One writing rule follows from that, write each item as a measure and a sentence at once: "at least 3 years of PostgreSQL experience" means something on both sides, "PG 3+" means something only to you.

Not every requirement you write makes it into scoring. The classifier that runs while you write the row looks at whether the measure can be verified from the CV or the application form, and flags the ones that cannot. This is the very classifier that runs when a candidate is scored; the warning at writing time and the check at save time cannot drift apart.

The reasons come under four headings. Working arrangement and availability: "in the office 3 days a week" is a condition, not a requirement. Cognitive ability: analytical thinking, problem solving. Soft skills: communication, teamwork, motivation. General: anything that cannot be verified from a CV or an application form and belongs in an interview instead. The texts live in a single dictionary, which is why the warning you see while writing and the check on the record say the same sentence.

A flagged row is not deleted from the list, but it produces no rubric item; the percentage you gave that criterion has no counterpart in scoring. A warning dialog opens before saving and the save pauses, yet you can still say save: the warning is advice and never stops the record. The right move is usually to take the row out and move the same measure to the interview or to the application form.

The Responsibilities section is a plain list: no weights, no required flag, and the field itself is optional. Write the day to day content of the work here. It pays off twice: the candidate sees the role in concrete terms, and because the items count towards the body, they take pressure off the 300 character threshold as well.

When you set the status to Active and save, the posting drops into the list on the career page and opens at its own address. Taking a posting live spends one of the open posting slots in your plan; if the allowance is full, you have to close an open posting first. The gate only runs on the move from draft or closed to active, so a posting that is already active stays editable even when the limit has been passed.

The last job is to open the page in a separate tab and read it as a candidate. The top strip shows the department, the location, the contract type and the application deadline; an empty deadline reads "Open ended", a past one reads "Expired" and the apply button gives way to a closed notice. Check the description in the body and the requirement and responsibility items in the right column.

The form is split into six sections, but the screen the candidate sees is a single page. Knowing where each field surfaces makes it easier to pick your tone while writing: the top strip is scanned, the body is read. There are also fields that never appear at all, and if you do not know which, the information you wrote quietly disappears.

The table below gives the counterpart of every panel field on the candidate screen, along with the rule that governs saving it.

Every posting has its own address. Two gates decide whether that address reaches search results, and both of them have to be open. If one is closed, the page is shut off from search engines and never written into the sitemap either.

With both gates open the rest runs by itself: the job posting markup is produced on the server and there is no extra setting for you to configure. The only job left to you is not leaving the fields that feed the markup empty.

On the second route of the switch at the top of the form you write a free brief ("We are looking for a senior backend developer for our Istanbul office, with at least 4 years of Node.js experience") and get back an editable draft: title, description, weighted requirements, decision bands, missing field warnings. The draft is generated, not saved; you are still the one who saves it.

Two behaviours of the draft matter. The first is that it does not invent: hard facts such as the location, the department, the deadline and the employment type stay empty when the brief does not carry them, surface as missing fields, and the record is not completed until you fill them in. The second is that it audits itself: requirements the model proposed but which cannot be verified from a CV are taken out of the scored list and shown separately with the reason. You can put those items back into the posting text as plain prose.

This route depends on the plan and on a company setting. AI posting generation is open on the Trial, Professional and Enterprise plans and closed on Mini and Starter. While the AI analysis switch in company settings is off, the request never even reaches the plan gate. Every generation spends one AI evaluation credit. Writing a posting by hand works on every plan; every step in this guide is the same there.