A job description should help the right person recognise the work and decide whether to explore it. A long list of languages, frameworks and personality traits often makes that decision harder. For an ML engineering role, begin with what the engineer will own and the environment in which they will work.
Lead with a problem worth solving
Explain the product and the technical challenge in plain language. “Improve how customers find relevant documents” communicates more than “join our revolutionary AI journey.” Describe why the role exists now and what the current team has already built.
Make uncertainty visible. If the team is still testing whether an approach will work, say so. If the model is established and the challenge is reliable delivery, describe that instead. Candidates should not have to infer whether they are joining a research effort or an operational engineering team.
Separate outcomes from activities
“Work with data scientists” is an activity. “Make model releases reproducible and easier to investigate” describes an outcome. Include a few outcomes that reflect the actual scope without promising an arbitrary timetable before the engineer has seen the system.
Then describe the work that supports them: maintaining pipelines, implementing evaluation, reviewing changes, monitoring behaviour or improving the deployment process. State which responsibilities belong to other team members.
Keep essential requirements defensible
For every must-have, ask what work would be impossible without it and whether an adjacent skill could transfer. Familiarity with a particular library may be helpful without being essential. Independent production ownership may be essential even when the exact stack differs.
Do not combine the requirements for an applied engineer, infrastructure specialist and research scientist unless the role truly needs that breadth and the organisation can support it. If the list keeps expanding, prioritise the first business problem.
Use this brief as a starting point
Make the proposition concrete
Include the working arrangements and compensation range where you can make an accurate commitment. Explain access to technical peers, decision-making authority and the constraints of the environment. Avoid implying unlimited autonomy if important decisions require several approvals.
Before publishing, ask a technical colleague to describe the role back to you after reading it. If their interpretation differs from yours, resolve the ambiguity. Then use the same outcomes in the interview scorecard, so the job advertised is the job assessed.