Writing AI and ML job descriptions people want to apply to

Lead with the problem, not the perks

ML candidates want to know what they will work on and what state it is in. Open with two sentences on the problem the model solves and what this hire will own. Perks and mission statements can wait.

A strong opening sounds like: “Our support assistant answers customer questions with a fine-tuned open-weights model. You will own its evaluation suite and lead the next round of fine-tuning.” It is specific, and it tells a candidate immediately whether the work suits them.

Say whether the work is research, prototyping or production. A researcher who wants to publish and an engineer who wants to ship read the same title very differently, and both will drop out late if the posting misled them.

Be specific about the ML work

List the stack you actually use, not the one you hope to adopt. If you are moving from scikit-learn to PyTorch, or from API calls to your own models, say so: many candidates will find the move interesting, and none will feel misled.

Then describe what makes ML work possible: the data (how much, how clean, whether it is labelled), the compute (GPUs, a cluster, a cloud budget) and how models reach production. Candidates read these details to judge whether they will be able to do good work at your company.

Requirements vs. nice-to-haves

Keep the must-have list to five items or fewer, and move everything optional to a clearly labelled “nice to have” section. A long list of requirements discourages strong candidates who meet most of them, and rarely filters out weak ones.

Ask for a PhD only when the work needs research training, such as a research scientist role. For applied and engineering roles, ask for evidence of the skill instead: models shipped, evaluations designed, papers reproduced.

Avoid years-of-experience requirements on fast-moving tools. “5+ years of LLM experience” asks for something few people can have. Describe what the person must be able to do instead.

Salary ranges are not optional

Every job on TensorHunt needs a salary range before it goes live. Ranges let candidates decide early whether the role fits, so neither side finds out three rounds in that the numbers never matched.

A growing number of US states and cities also require pay ranges in job postings, and some of those rules cover remote roles open to their residents. Check the rules for wherever your candidates may live.

A format that works

Start with the title and a two-sentence description of the problem. Follow with what the person will work on, in specific bullets, then a short description of the team: its size, who it reports to, and how it works with product and research.

Next come the stack and the data and compute available, a short list of requirements, a separate nice-to-have list, and the pay. Put pay before the company background, so candidates do not have to scroll past the mission statement to find it.