Turn a messy hiring conversation into a one-page software job brief

Capture the raw brief in ten minutes

Before you open a chat tool, write or voice-memo only what you already know:

1. Mission in one sentence — e.g. “Own the booking API and cut p95 latency on checkout.”
2. Outcomes for 30 / 60 / 90 days — three bullets max each, measurable where you can
3. Real stack — languages, services, repos, cloud pieces you use today (not a wish list)
4. Collaboration — who they work with (product, design, support), and how often
5. Constraints — remote/hybrid, timezone overlap, on-call, compliance, budget band if you share it
6. Anti-requirements — what this role is not (no people-management, no greenfield rewrite, no “full-stack plus sales”)

Paste that block. Say: “Do not invent tools, titles, or must-haves. Mark gaps as [NEED].”

Ask for structure, not poetry

Use a fixed skeleton so the model cannot wander:

Turn these notes into a job brief with sections:
Role title (suggest 2 options only from my notes),
Mission, Outcomes (30/60/90), Responsibilities,
Must-have skills, Nice-to-have skills,
Collaboration, Constraints, Interview signals.
Keep under 500 words. No hype. No invented stack.

Then a second pass: “Tighten. Cut buzzwords. Move anything I did not mention into [NEED].”

Two passes beat one request to “make it sound senior.”

Scrub the inventing

Read the draft with a red pen. Delete or fix:

• Tools you do not use (“must know Kubernetes” when you run a simple PaaS)
• Seniority theater (“10+ years” when you need strong mid-level ownership)
• Soft-skill filler that screens nobody (“passionate thought leader”)
• Duties that belong to another role

If the model added a must-have, demote it to nice-to-have or remove it. Invented requirements shrink your pool and waste interview time.

Must-have vs nice-to-have

Force an explicit split:

• Must-have — without this, they cannot do the job in your environment
• Nice-to-have — speeds ramp, not a reject reason

Ask the model: “Recategorize skills. Anything not in my notes becomes nice-to-have or [NEED]. Cap must-haves at five.”

Five must-haves is already a lot for most product teams.

Turn the brief into posting copy last

Only after the brief is true:

1. Ask for a short public posting draft from the brief
2. Ask for a scorecard (signals you will look for in interviews)
3. Have engineering and product skim both in one sitting

Do not generate the public post first. Marketing polish on a fuzzy brief spreads the fog.

A one-week habit for the next hire

• Day 1: capture raw notes with the hiring manager
• Day 2: AI structure + scrub
• Day 3: scorecard from the brief
• Day 4: public post from the brief (not the other way around)
• Day 5: freeze the brief; change it only when the role changes

Save the brief next to the role folder. Next quarter you will not reinvent the role from Slack memory.

Worked example (pattern only)

Suppose your notes say: own payments webhooks, TypeScript monorepo, on-call with two others, no people management. A draft that adds “must know Go, Kubernetes, and 8+ years leading teams” is wrong even if it sounds impressive. Scrub to the notes. Keep TypeScript and webhook ownership as must-haves; put Go/K8s in nice-to-have only if someone on the team truly wants them. That scrub is the job.

Short close

Outcomes and constraints in, invented stack out—that is an AI-assisted job brief worth posting.