How do you define hiring evaluation criteria?

An evaluation criterion is a single measure you look at while reading an application. It carries two conditions at once: it tells candidates apart, and it can be verified from a document you already hold. "Join a dynamic team" in the posting text is the pitch; "at least 3 years of PostgreSQL experience" is a criterion, because it gives two candidates different answers and has something to look for in a CV.

Writing the criteria down is not enough, you also have to say which one matters more. A list without weights says every item is equal; in most roles one item outweighs the other three put together. In the panel every requirement row has its own percentage and its own "Required" switch, and the two work independently of each other.

The criteria you write turn up in three places: as the weight distribution on the posting form, as rubric items on the saved posting, and as decision bands once a score exists. This guide sets the three up in that order.

• Criterion: written item by item in the "Requirements & Weights" section of the posting form; every row gets a percentage and a "Required" switch.
• Rubric: the criteria are broken into check items once per posting, stored, and applied identically to every candidate.
• Decision bands: which range of the 0-100 score counts as strong, review or weak is stored per posting.

Open the Jobs area in the panel, go to the Postings tab and open the posting. The note on the "Requirements & Weights" section sums the work up: write criteria that tell candidates apart and can be evaluated from a CV, and make the weights add up to 100.

The moment you type a line, a deterministic classifier reads it. If the criterion cannot be verified from a CV, the row turns amber and the reason appears underneath it under the heading "AI cannot analyze this". Those reasons fall into four headings and their wording comes from a single dictionary, so no screen in the panel words them differently.

The warning is not decoration, it is the very triage used in scoring: the indicator you see while typing and the way a candidate is scored hang on the same classifier. A flagged row gets a "Suggest a fix with AI" button; one request returns a rewrite that can be evaluated from a CV, and "Apply this suggestion" puts it in place of your text.

• Working pattern and availability ("three days a week", "in the office"): cannot be verified from a CV, this is a condition.
• Cognitive abilities (analytical thinking, problem solving): cannot be verified objectively.
• Soft skills (communication, teamwork, motivation): cannot be verified objectively.
• General: the criterion cannot be verified from the CV or the application form, it belongs in an interview.

Every requirement row has a narrow percentage field on its right. As you type, the badge under the list counts the total live and shows it as "Total: X / 100". If the total is not 100, or one row is left without a weight, both the badge and the error text beside it turn destructive.

The rule is enforced on both sides. The Save button never opens on the client and its reason stays printed under the form: "Requirement weights must sum to 100 before saving." The server runs the same schema again at write time, so there is no way to slip past the rule from the client.

One question is enough while you divide the budget: when I cannot choose between two candidates, which item do I look at. That item takes the highest percentage. Rather than splitting the rest evenly, leave clear gaps; 40 / 30 / 20 / 10 produces a ranking, 25 / 25 / 25 / 25 does not.

Every criterion row carries its own "Required" switch, and that flag works independently of the weight. A criterion weighted 15 can be required while one weighted 40 is not. Weight answers "how important is this", required answers "can we do without it".

The required flag eliminates nobody. An unmet required criterion puts a cap on the candidate score; the default cap is 54. The candidate stays on the list, the score cannot climb above the cap, and the call is still yours. GoTeam eliminates no candidate on its own: AI produces suggestions, and the status is always changed by a person.

To become a precondition, a criterion has to be measurable. Two routes are accepted: the text parses into the "at least N years of <technology>" pattern, or the category of the criterion is years of experience, degree, language level or grade average. A free form skill statement ("knows React") cannot be a precondition, because an elimination gate is not built on interpretation.

• The years calculation is not asked of the model, it happens in code: 12 of 12 hard edge cases were decided correctly and no wrongful elimination came out.
• A gate returning "unknown" does not mean "closed"; an unclear item leaves both the numerator and the denominator, and the candidate is not penalised.
• Field of study or degree criteria ("graduate of ... Engineering") are never promoted to required on their own; a candidate from another field does not hit the cap over a diploma line alone.
• A university year criterion ("must be a third or fourth year student") counts as an eligibility condition: it is hard even when it is off by default, and it is verified from the application form declaration rather than the CV.

The "Scoring Bands" section of the same form has three numeric fields: "Strong threshold", "Review threshold" and "Weak threshold". All three are percentages and their defaults are 55, 35, 20. Which band a score is read in follows from those three numbers; a score under the weak threshold counts as "missing".

The order cannot break: the strong threshold has to be strictly greater than the review threshold, and the review threshold strictly greater than the weak one. Not even equality is allowed, "strong 50, review 50" will not save. When the rule breaks, a red error appears and Save stays closed.

Band labels come from a single source in the product: strong, review, weak and missing. The engine, the API and the interface use the same dictionary, and no screen derives a verdict of its own from a raw number. A score that was never calculated also sits in the missing band, but that is not the same as a zero: the absence of evidence is not held against the candidate.

The rubric section is only drawn on a saved posting, because generation runs off the stored criterion list of that posting and the resulting version is bound to it. When you ask for "Generate rubric", the criteria are broken into check items: at most four items per criterion, all in a single call and without a single candidate being seen. The output is stored and applied identically to everyone who applies.

Approval happens item by item. For each item you are shown one example that meets it and one that does not, and you approve after seeing both. A bulk approve button is deliberately absent; the screen says so in its own note. The badges on an item read "Elimination gate", "Usage condition" and "Weight N", the last one stating its relative importance inside the rubric.

Criteria that cannot be verified from a CV never enter the rubric; those findings are listed in a separate warning box ("N criteria that cannot be verified from a CV were left out of the rubric"). If no gate item could be produced for a required criterion, the system does not turn some random item into the gate, it raises the missing gate as a validation finding on the approval screen.

The most common mistake while writing criteria is copying a wish from the posting text into the criterion list. "Team player", "eager to learn" and "three days a week in the office" belong to the pitch. Since none of them can be verified from a document, they have no counterpart in evaluation and they burn weight budget for nothing.

The second mistake is subtler: the criterion is verifiable but written in a way that cannot be measured. The system does not reject such a row and it still takes its weight; it only trips the measurability test the moment you try to build a precondition on it.

Part of criterion setup concerns one posting only, part of it changes every posting in the company at once. Mixing the two is the most common setup mistake: changing the company wide preset because a single posting should be "a bit stricter" shifts the behaviour of every open posting.

There are three company wide presets: Balanced (the default), Strict and Lenient. Strict pulls the cap for an unmet required criterion down to 40 and keeps the default requirement behaviour on. Lenient lifts the cap to 60 and turns the default requirement off. This screen is separate from the per posting decision bands.

A practical rule: if the ranking on one posting is not coming out the way you expected, look first at the criteria, the weights and the bands of that posting. Touch the company wide setting only when you see the same drift on several postings.

If calibrating criteria were expensive nobody would do it, so the price of this path was kept low on purpose. One candidate and posting pair is charged only once; no credit is spent when a rescoring follows a change to the criterion text, a weight or a band. Stored coverage calls are re-added locally and no new model request is needed.

The change is not silent either. On a posting that already has analysed applications, trying to save an edit to a criterion text, its weight or its required flag opens a confirmation window that tells you with a number how many analyses will be affected. If nothing changed, or no analysis is affected, the window never opens.

Being able to look back is part of the setup too: every score record keeps the version, the model and the gate rationale, so why a candidate ended up in that band can be shown afterwards. The system does not learn from past hiring outcomes; who was invited or hired never enters scoring, which means the ranking does not drift on its own as long as you leave the criteria alone.

• Writing criteria, weighting, decision bands and rubric approval are locked on no plan; the screens ask for posting view and update permissions.
• The path that drafts criteria and bands from a free text (AI posting generation) is open on Professional, Enterprise and the 14 day trial; it is closed on the Mini and Starter plans. While it is closed you write the criteria by hand and the rest works the same.
• Rubric generation spends one AI evaluation credit per posting; the requirement check and the re-adding that follows a band or weight change are free.
• While the AI analysis switch in company settings is off, the scoring settings and the re-analysis endpoints close, and a generated rubric has no counterpart in scoring.