Every slow engineering search I have watched had the same first cause: a brief that described a technology stack instead of a job. "Senior React developer, 5+ years, TypeScript, AWS a plus" tells a recruiter what to grep for and tells a good engineer nothing about whether they want the role — and it gives whoever is sourcing no way to rank two candidates who both match the keywords.
A brief that works is about one page and answers six questions. Here they are, with the version that fails next to the version that works.
1. What problem will this person own?
Not the team, not the department: the problem. "Our checkout has a 4% failure rate we cannot explain and nobody owns the payment path end to end" is a brief. "Join our payments team" is a description of seating.
This is the single highest-value line in the document. It is what a senior engineer reads to decide whether the role is interesting, and it is what lets someone screening candidates judge relevance instead of keyword overlap.
2. What will they actually touch?
List the stack, but attach it to the work: "Node and Postgres in the payment service, React on the checkout front end, Terraform for the two pipelines they will own." A list of fourteen technologies with no indication of which matter produces candidates who match on the wrong nine.
Mark each one as must, useful or will learn. Most briefs have one or two genuine musts and pretend to have six, which is how good candidates get filtered out over something nobody actually cared about.
3. What does seniority mean in this role?
"Senior" is the least portable word in hiring. Decide which version you mean, because they filter differently:
- Can design a subsystem from a vague problem statement and defend the trade-offs.
- Can take an ambiguous business request and come back with three options and a recommendation.
- Can carry a production system on call without escalating every incident.
- Can raise the level of two mid-level engineers by working next to them.
Pick the one or two that matter for this role and write them down. Candidates are then evaluated against something real, and you will notice quickly that some "senior" candidates are strong on one axis and absent on another.
4. What hours do you genuinely need?
Be specific and be honest, because this is where an engagement quietly breaks in month two. "Standup at 9:30 AM Eastern, plus available until 3 PM Eastern for live work; the rest is async" is a requirement someone can accept or decline. "Some overlap required" is not.
The arithmetic is worth doing before you write the line. Brazil is UTC−3 all year with no daylight saving, so an engineer on ordinary Brazilian hours overlaps nearly the whole working day with U.S. Eastern time, six to seven hours with Central, and four to five with Pacific — and the gap shifts by an hour when the U.S. changes its clocks. The overlap calculator gives you the exact window for your zone, and the time zone guide covers the seasonal shift.
If what you actually need is a 4 PM Pacific meeting every day, say so. It is a real constraint with a real answer, and finding out in week six is much worse than hearing "that one is hard" in week one.
5. How will you decide?
Write your own process into the brief: who interviews, in what order, how long each stage takes, and who signs off. Two reasons. It forces you to notice that your process has a ten-day gap in the middle where one person is on holiday, and it lets whoever is sourcing tell candidates something concrete, which is most of what keeps a strong candidate engaged.
Include the start date you want. "As soon as possible" is not a date, and it is the reason two candidates get held for a role that turns out not to start for six weeks.
6. What are your deal breakers?
The things that would make you say no regardless of how good someone is. Common real ones: no prior fintech experience is fine but no relational database depth is not; must have worked on a team larger than three; must be comfortable with a code base nobody has documented; cannot be simultaneously engaged elsewhere.
Deal breakers are more useful than requirements, because they are shorter and they are actually true. Three is a healthy number. Ten means they are wishes.
What to leave out
- Years of experience as a proxy. "8+ years" filters on birthday rather than ability. If you mean depth, describe the depth.
- Culture paragraphs. "We work hard and play hard" costs you a quarter of the page and changes no decision.
- The full technology inventory. Anything they will not touch in the first six months is noise.
- A salary range you will not honour. If it is fixed, say the number.
What a finished brief looks like
Concrete beats abstract, so here is a complete one. It is short on purpose.
Problem. Our checkout fails on about 4% of attempts and nobody owns the payment path end to end. We need someone to take it, instrument it, and bring the failure rate under 1%.
Stack. Must: Node, Postgres, a payment provider integration in production. Useful: React for the checkout front end, Datadog. Will learn: our internal event bus.
Seniority means. Can take "checkout is flaky" and come back with three hypotheses, a way to test each, and a recommendation. Can carry the service on call.
Hours. Standup 9:30 AM Eastern, available to 3 PM Eastern for live work, rest async.
Process. Written brief and video, then 90 minutes with our staff engineer, then a four-hour exercise on our real checkout logs. Decision inside eight business days. I sign off, nobody else.
Deal breakers. No production payments experience. Cannot be on call. Simultaneously engaged elsewhere.
Start. First week of next month.
That is under two hundred words, and it is enough to source against, to rank candidates against, and for a candidate to decide whether they want it. Notice what is absent: years of experience, a culture paragraph, and eleven technologies the person will not touch.
Why the brief decides the timeline
Good candidates in a specific stack exist and are findable; the bottleneck is almost never sourcing. It is the round trip that follows a vague brief — a shortlist arrives, the hiring manager says "not quite", nobody can articulate why, and a week disappears while everyone reverse-engineers what was actually wanted.
A one-page brief that answers the six questions above removes that round trip. It is why our process starts with a written brief rather than a call, and why the first vetted candidates for common stacks arrive within five business days — the specification exists before anyone starts looking. When you are ready to write one, send it over in whatever shape it is in; half a brief with the six questions answered beats a polished job description that answers none of them.