The three parts
| Part | What goes in | Example |
|---|---|---|
| Must-haves | Three to five things without which you would not interview | "Has shipped a production backend in TypeScript or Go" |
| Either/or profiles | Different backgrounds that each fit | "Either 3+ years at a startup under 50 people, or built and launched a product of their own" |
| Bonuses | Signals that lift a candidate | "Has worked with Postgres at scale", "open-source work" |
Five rules
- Make it checkable. "Strong communicator" cannot be verified from a resume. "Has written public technical posts or docs" can.
- Say why. "Worked at a company under 50 people, because nobody will hand them a spec" lets the screener recognize equivalent experience you did not list.
- Keep must-haves few. Every must-have removes candidates. With ten of them, nobody passes.
- Name what does not matter. "Degree not required" and "years of experience matter less than what was shipped" prevent false rejections.
- Stay on the job. Nothing about age, gender, origin, family or gaps in a career. Besides being unfair, in many countries it is illegal.
Three examples
Founding engineer
Must: has shipped a production web product end to end; TypeScript and a relational database; has worked where they owned a feature from idea to release. Either: an early engineer at a startup under 30 people, or a solo builder with a launched product and real users. Bonus: has been on call for their own code; writing that shows clear thinking. Does not matter: degree, big-company names.
Account executive
Must: two or more years closing B2B software deals; has carried a quota and states the number; sold to the kind of buyer we sell to (heads of people, founders). Either: full-cycle seller at a startup, or a top performer at a larger company who has also prospected for themselves. Bonus: first sales hire before; HR tech background.
Product designer
Must: a portfolio with shipped product work, not only concepts; has designed complex web application screens such as tables, settings and workflows; works directly with engineers. Either: the only designer at a startup, or a designer at a product company who owned a whole area. Bonus: writes interface copy; can prototype in code.
How Evander uses the brief
In Evander the brief is the instruction the screener works from. Every application is checked against each requirement, each check links to the evidence in the resume, and the result is a score from 0 to 100 with reasons. When you disagree with a score you override it, and your overrides become examples for the next applicants. A person decides who moves forward; the score only orders the list.
Common mistakes
- Pasting the job post as the brief. A post sells the role; a brief decides who gets a call.
- Listing tools instead of outcomes. "Kubernetes" matters less than "has run production infrastructure".
- Never revisiting it. Read the first twenty scores, find where you disagree, and adjust the brief.
Questions
What is a screening brief?
A short written description of who should get an interview for a role: three to five must-haves, either/or profiles that would each fit, and bonuses. AI screening checks every applicant against it.
How many must-have requirements should a role have?
Three to five. Each must-have removes candidates, and with ten nobody passes. Put everything else under bonuses.
What is a good ATS score?
A score only has meaning against the brief it was computed from. In Evander scores run from 0 to 100 with the check behind each requirement; teams usually interview from the top of the ranked list rather than above a fixed number.
Can AI screening replace reading resumes?
It replaces reading all of them. AI ranks every applicant with reasons, and a person reads the top of the list and makes the decision. Spot-check a few low scores to make sure the brief is right.