Most failed tech searches fail before the first candidate is ever contacted, in a document almost nobody treats as important: the requirements profile. When it is a copy-pasted list of every tool the team has ever touched, sourcing targets the wrong people, interviewers score against different imaginary roles, and the offer goes to whoever happened to survive the noise. A good requirements profile is short, brutally prioritized, and written in outcomes rather than tool names. This article gives you the exact structure, section by section, plus a filled-in miniature example you can adapt.
What goes wrong without a real requirements profile
Skipping the requirements profile does not save time, it moves the cost downstream, where it is far more expensive. The typical failure modes are predictable enough to list.
| Failure mode | What it looks like | What it costs |
|---|---|---|
| Unicorn profile | Fifteen "required" skills spanning three real jobs | Near-empty pipeline; strong candidates self-select out |
| Interviewer drift | Each interviewer tests their own imagined version of the role | Contradictory feedback, decisions made on gut feel |
| Keyword sourcing | Sourcing matches tool names instead of capability | Fluent talkers pass, builders get filtered out |
| Level mismatch | Senior title, mid-level scope and salary band | Offer-stage rejections after weeks of process |
| Scope creep | Role redefined mid-search as stakeholders weigh in | Search restarts; candidates in process are lost |
The template: eight sections, one to two pages
A requirements profile should fit on one to two pages. Longer documents are not more thorough, they are less prioritized. Copy this structure.
- 1Role context (3-4 sentences): why this role exists now, what changes in the business if it is filled well, who it reports to.
- 2Mission of the role (1 sentence): the single outcome this person owns, e.g. "own the path from ML prototype to reliable production service."
- 3Top 3 outcomes for the first 12 months: concrete, verifiable results, each with a rough success signal.
- 4Must-have capabilities (max 7): outcome-phrased abilities that are genuinely deal-breaking, each with an evidence hint (what proof would look like).
- 5Nice-to-have capabilities (max 5): explicitly labeled as tie-breakers, never used to reject.
- 6Seniority calibration: what the person decides alone, decides with others, and escalates, plus the ambiguity level they must handle.
- 7Working context: team setup, stack (as context, not requirements), remote/on-site reality, on-call or travel expectations.
- 8Explicit non-requirements: things people will assume are required but are not (e.g. a PhD, a specific framework), to widen the pool deliberately.
Must vs. nice-to-have, and outcomes over tool lists
The two disciplines that separate a working profile from a wish list: every requirement earns its place as a genuine deal-breaker, and every requirement is phrased as something the person can do, not something they have used. A tool can be learned in weeks; the outcome behind it takes years. The table shows the rewrite.
| Tool-list version (weak) | Outcome version (strong) | Evidence to ask for |
|---|---|---|
| 5+ years Python, pandas, scikit-learn | Can frame a fuzzy business question as a modeling task and ship a first useful model in weeks | Walk-through of a past project from question to shipped result |
| Kubernetes, Docker, Terraform, MLflow | Can take a model from notebook to monitored, rollback-safe production service | Architecture discussion of a system they ran in production |
| Experience with LLMs, RAG, LangChain | Can design and evaluate an LLM feature against quality, cost and latency budgets | A concrete eval setup they built, with its failure cases |
| Strong communication skills | Can get a skeptical domain expert to trust and adopt a model's output | A story of adoption resistance and how they resolved it |
Seniority calibration and the anti-unicorn rule
Years of experience is the weakest seniority signal in tech. Calibrate on scope and ambiguity instead: what does this person decide without asking, and how underspecified can a problem be before they stall? Then apply the anti-unicorn rule as a hard check on the finished draft.
- 1Count the must-haves. More than seven: split the role or demote requirements to nice-to-have.
- 2Check for role mixing: if the must-haves span two distinct jobs (e.g. research-grade modeling AND platform engineering), you are describing two hires.
- 3For each must-have, ask "would we really reject an otherwise excellent candidate over this?" If the honest answer is no, it is a nice-to-have.
- 4Match level to decisions: a senior profile should name decisions the person owns alone; if every decision routes through a lead, the role is mid-level regardless of the title.
- 5Sanity-check the market: if fewer than a few hundred people plausibly match the profile in your hiring geography, either the salary band or the profile has to change.
A filled-in miniature example
An illustrative excerpt for a fictional mid-size company hiring its first ML engineer, condensed to the core sections. It is deliberately short; a real profile would add working context and non-requirements.
| Section | Content (condensed) |
|---|---|
| Mission | Take our two validated ML prototypes into reliable production and establish how we ship models from now on |
| Top outcome, year 1 | Demand-forecast model live in the ordering workflow, with monitoring and a documented retraining path |
| Must-have 1 | Has taken at least one model from prototype to production and operated it (evidence: system walk-through) |
| Must-have 2 | Can build pragmatic data pipelines on a cloud stack without a platform team behind them |
| Must-have 3 | Can explain model limits to non-technical planners and design the workflow around them |
| Nice-to-have | Retail or supply-chain domain exposure; experience choosing build-vs-buy for ML tooling |
| Seniority | Decides architecture and tooling alone within budget; escalates scope changes to Head of Data |
Common mistakes to avoid
- 1Copying requirements from other companies' job ads, which imports their org structure and their mistakes into your profile.
- 2Letting every stakeholder add a requirement without forcing a trade: additions are free for them and fatal for the pipeline.
- 3Using the profile only for the job ad, then interviewing against memory: the profile should generate the scorecard every interviewer uses.
- 4Writing the profile after sourcing has started, so it justifies the candidates already found instead of defining who to find.
- 5Treating the stack section as requirements: the stack is context; forcing tool-for-tool matches filters out exactly the adaptable seniors you want.
