Four sentences that decide your shortlist

We ask for a short description of the role before we build a shortlist, and clients often send a job description instead. They are not the same document, and sending the wrong one costs you a round of interviews.

Two documents, one job

A job description is written to attract. It goes on a careers page, it competes with other job descriptions, and so it drifts outward: every skill anyone on the team might eventually want, a paragraph about culture, a range wide enough to stay flexible. That is the correct shape for the job it is doing.

A role description is written to select. It only has to tell one person, who is about to go and find you two or three candidates, what distinguishes the right one from the plausible one. Everything that does not distinguish is noise.

You can tell the two apart by a simple test: delete any sentence that would still be true for a different company hiring the same title. A job description barely shrinks. A role description should lose almost nothing, because it is made of the specifics.

The four sentences

Four things change the shortlist. Everything else is useful context.

What gets done, in the first person. Not "responsible for customer support." Instead: "clears the overnight queue every morning, answers from our help center in our tone, and escalates anything that looks like a bug." That sentence tells us whether we are looking for speed, judgment, or writing, and those are three different people.

The hours you need covered. As a window, in your own time zone. This is the question most role descriptions skip and most placements fail on. "9 to 5 Eastern" and "overlapping four hours with Eastern" produce different shortlists and different prices everywhere in the market.

The tools the work happens in. Including the ugly internal one nobody wants to name. Somebody who has lived in your help desk for three years is worth more than somebody with a better CV and a two-week ramp on it.

Who reviews their work. A named person, not a department. This is as much a test of the description as an input to it. If you cannot answer it, the seat is not ready, which is worth knowing before you interview six people.

You can skip the wish list

Send the job description too if you have one. We will read it. But we will still ask what the person does in their first week, because the job description is almost never an answer to that.

Years of experience are the least useful line in most role descriptions. A requirement of five years in a role filters out a strong third-year candidate and lets through a weak seventh-year one, and neither of those outcomes is what you wanted. We ask about level instead, which is about what somebody can own rather than how long they have been near it. The levels are defined on the rates page.

The other thing you can skip is the tooling wish list. If the person is good and the tool is learnable, two weeks closes the gap. Name the tools that take longer than that, and leave the rest off.

A real one

This is a role description a client sent us, unedited:

Shopify developer, mid level. Works our theme backlog on a staging theme, ships behind my review, and owns Core Web Vitals. 9am to 5pm Eastern. Shopify, GitHub, Linear, Slack. Reports to me.

Four sentences. Shortlist in five business days. They hired the second person they interviewed, and that person is still there.

Every sentence in it narrows the field. "Staging theme, ships behind my review" tells us they want somebody who can take direction, not somebody who wants autonomy on a live store, and those people are often different. "Owns Core Web Vitals" rules out a theme developer who has never looked at a performance trace. "Reports to me" answers the review question in three words.

Ten minutes to write. Saved them a round of interviews, which is worth far more than ten minutes.