Skip to content
SoTalented

How to write a brief that gets you the right hire

A good brief describes outcomes, not duties. Here is the template we use before sourcing anyone, with a worked example you can copy.

Template · Last reviewed 1 November 2026 · 3 min read

Most hiring briefs list duties: “responsible for testing”, “manages the content calendar”. Duties tell a candidate what fills the calendar. They do not tell anyone what good looks like. A brief that describes outcomes gets you better candidates, a fairer interview, and a baseline for the first review on day one.

Here is the template we fill in with you before we source anyone. It works just as well if you are hiring on your own.

The template

## Role
Title a candidate would search for:
Level (junior 1 to 2 years / mid 3 to 6 / senior 6+):
Start (month):

## Why the seat is open
Two or three sentences. The real situation, told plainly.

## What success looks like
Three to six outcomes, ranked. Each starts with a verb, ends in something
you could observe, and states its own time horizon.
1.
2.
3.

## What the work involves
Five to seven bullets on the day to day.

## Must-haves (maximum 7)
Each one checkable in a 15-minute call, with a question or a document.

## Nice to have (maximum 5)

## How you will work together
Who manages them, which tools, which rituals (standup, weekly review).

## Interview process
Every stage you will run, and roughly how long it takes.

The rules that make it work

  • Outcomes, not duties. “By day 60, a regression suite exists and no release goes out untested” beats “responsible for managing the testing process”.
  • Must-haves are checks, not adjectives. “Excellent communication skills” cannot be screened. “Can explain a bug to a product manager in two sentences” can.
  • Cap the lists. Seven must-haves at most, five nice-to-haves at most. Labelling everything as required filters out the coachable people you want.
  • Name every interview stage. Then do not add one later. Good candidates drop out of processes that keep growing.

A worked example

This one is hypothetical: a 15-person software company whose releases keep slipping.

Role. QA engineer, mid level (3 to 6 years).

Why the seat is open. Say the team ships every two weeks and developers test their own work at the end of the sprint. Releases slip, and bugs reach customers. This is the first QA hire, so they will set how testing works.

What success looks like.

  1. By day 30, a written test plan covers the three most-used flows.
  2. By day 60, an automated regression suite runs on every release, and no release goes out untested.
  3. By day 90, bugs found by customers are trending down, and the team agrees why.

Must-haves.

  • Has written and maintained automation in Playwright, Cypress or Selenium
  • Has owned testing for a whole release cycle
  • Can show a bug report they wrote, with steps, expected and actual results, and environment
  • Can hold a technical conversation in English with a developer and be understood first time

How you will work together. The person reports to the CTO, joins daily standup, and has a weekly 30-minute review.

Interview process. A screening call, a short paid task, a conversation with the CTO, then an offer.

What happens with the brief next

In a satellite office, this brief is the first of our 42 touchpoints. We use it to source and assess candidates, then send you a shortlist of around three people, each with assessment notes, salary expectations and our recommendation. The outcomes you wrote become the baseline for the first review.

A mid-level QA engineer costs $2,200 to $3,200 a month, all-inclusive. See the scenario in releases on schedule, tested, or bring your brief to a call: talk to us.

All posts