Hiring · July 21, 2026 · 9 min read

Prompt engineering by role: what good looks like

Prompt engineering by role is a core hiring skill, but 'good' differs for an engineer, analyst, support agent, SDR, PM or recruiter. A per-vertical hub guide.

← Part of The five pillars of hiring: what assessments measure

A year ago, prompt engineering sounded like a niche specialty. Now it is a baseline skill in almost every role that touches a keyboard — and for hiring managers and talent leaders, it is one of the highest-signal things you can measure, because it predicts whether someone ships the AI's mistakes or catches them. But here is what most hiring teams miss: good prompt engineering by role does not look the same across jobs. What separates a strong engineer is not what separates a strong support agent. This is the hub for our per-vertical cluster — a practical guide to what 'good' actually looks like in each seat, and where to go deeper for the role you are hiring.

Prompt engineering isn't one skill — it's role-shaped

The underlying competence is universal: give the tool clear context and constraints, then verify and correct what comes back. It is part of AI fluency, and the strongest signal is always the same — catching the AI when it is confidently wrong. But the task and the failure modes are role-specific, which is why phrasing tricks predict very little and a realistic, role-relevant task predicts a great deal. Below is how it plays out across the six verticals we assess, followed by the deep-dive guide for each.

Why prompting became a hiring signal

For most of the last decade, the tools a candidate used at work were invisible to the assessment. You measured the output and inferred the skill. AI tools broke that clean line. A confident-looking deliverable might be the candidate's own careful work, or it might be an unexamined paste from a model that was subtly, expensively wrong. The gap between those two outcomes is exactly what prompt engineering measures: not whether someone can produce a plausible answer, but whether they can tell a good answer from a plausible one.

That is why prompting has quietly become one of the highest-leverage things to assess. Hire someone who trusts the model uncritically and you have hired a channel for its mistakes; hire someone who treats every output as a draft to be verified and you have hired a multiplier. The difference does not show up on a CV, and it rarely shows up in a conversation about how someone uses AI — people describe themselves as careful far more often than they are. It shows up when you watch them work on a real task, which is the whole argument for assessing it directly.

The universal skill, then the role-specific edge

Every strong prompt has the same shape underneath. The candidate supplies context the model could not have guessed, states the constraints that matter, and — crucially — reads the result with suspicion rather than relief. Where roles diverge is in what 'wrong' looks like and how costly it is to miss. An engineer's miss compiles and ships a bug; an analyst's miss becomes a number in a board deck; a support agent's miss reaches an already-frustrated customer. The verification muscle is universal, but you can only see whether a candidate has it by giving them a failure mode from their actual job to catch.

Software engineer

Ask an assistant to write an async API client with retry logic. A strong candidate specifies the constraints up front — modern async patterns, explicit error handling on the right exceptions — reads the generated code, and catches the subtle problems: a deprecated call, a retry that swallows the wrong error, a missing edge case. Then they fix and test them. Good prompting here is inseparable from code review. See what else to test in a software engineer assessment.

• Good: constrains the request, reads the output, catches deprecated or unsafe code, verifies with a quick test.
• Weak: pastes the generated function and ships it, unhandled edge cases and all.

Data analyst

Ask for a SQL query — say, net revenue by month excluding internal test accounts — or for an interpretation of a result. A strong candidate defines the metric and the exclusions in the prompt, sanity-checks the numbers against what they already know, and questions a confident-but-misleading aggregate rather than pasting it into a report. The prompting skill and the analytical judgement are the same muscle. More in the data analyst assessment.

• Good: specifies the metric and exclusions, sanity-checks the output, distrusts a number the data doesn't support.
• Weak: accepts a plausible query, reports a figure that quietly doesn't add up.

Customer support

Ask the AI to draft a reply to a frustrated customer. A strong candidate gives it the relevant policy and the tone they want, then checks the draft for accuracy, softens anything that reads as robotic or dismissive, and removes an over-promise the model slipped in. In support, the prompt is only half the job — the edit is where the judgement shows. See the customer support assessment.

• Good: supplies policy and tone, verifies accuracy, adjusts to genuine empathy, cuts over-promises.
• Weak: sends a generic AI reply that's wrong on policy or tonally off.

Sales development

Ask for a cold email to a specific persona. A strong candidate feeds the tool real context — who the buyer is, the value proposition, the one clear ask — personalises the result, trims it to something a busy VP would actually read, and catches any hallucinated 'fact' about the prospect before it goes out. The prompt sets it up; the judgement keeps it credible. More in the sales development assessment.

• Good: gives context, personalises, tightens to a crisp ask, catches a fabricated detail.
• Weak: fires off a generic templated blast — sometimes with a made-up fact in it.

Product manager

Ask for a first draft of a spec or a prioritisation. A strong PM frames the problem and constraints clearly, uses the AI to get a fast starting point, then applies real product judgement — catching a flawed assumption, cutting scope the model over-added, grounding it in users and metrics rather than shipping the draft as-is. See the product manager assessment.

• Good: frames the problem, uses AI for a draft, then applies judgement — catches bad assumptions, ties it to real goals.
• Weak: ships an AI-generated spec with no product thinking layered on top.

Recruiter

Ask the AI to draft an outreach message or a screening rubric. A strong recruiter supplies the role context and the must-have signals, then checks the output for bias, generic filler and any claim about the role that is not actually true — and rewrites it into something a candidate would trust. Prompting well here is talent judgement in another form: knowing what good looks like before the model guesses. More on the recruiting side in how to hire a recruiter.

• Good: supplies role context and signals, screens the output for bias and filler, keeps every claim true.
• Weak: sends a generic AI-written blast that overstates the role and reads like spam.

Go deeper: a full guide for each role

Each vertical gets its own deep-dive — the best practices, a worked prompt, the good-versus-weak signals and how it is assessed:

• Prompt engineering for software engineers — prompting as code review in reverse.
• Prompt engineering for data analysts — precise definitions, then distrust the number.
• Prompt engineering for customer support — the draft is easy, the edit is the job.
• Prompt engineering for sales development — context in, credibility out.
• Prompt engineering for product managers — AI drafts, judgement decides.
• Prompt engineering for recruiters — talent judgement, applied to the model.

Two ways teams get the assessment wrong

The first mistake is the prompt quiz — asking candidates to describe how they would phrase a request, or grading them on knowledge of prompting tricks. This measures vocabulary, not judgement, and it is trivially gameable by anyone who has read a few threads on the subject. The second mistake is the opposite over-correction: banning AI in the assessment entirely because you are worried about cheating. That tests the job as it existed two years ago, not as it is done today, and it filters for the wrong candidates — the ones who cannot work with the tools everyone else already uses.

Both mistakes share a root cause: they treat prompting as a thing you know rather than a thing you do. The way through is to stop testing knowledge about AI and start observing collaboration with it, on a task that carries the failure modes of the actual role. That reframing also solves the integrity worry, because when AI use is expected and the task is generated per job, the fastest route to a good result is genuine skill — the same logic behind our approach to preventing cheating on AI-generated assessments.

How to assess it

You cannot measure any of this with a quiz about prompts, and you certainly cannot measure it by banning AI. You measure it by putting the candidate in a realistic, role-relevant task with AI tools available and watching how they work — which is exactly what an AI Sandbox assessment does, and how AI fluency is measured as a pillar. It is the honest way to test the job as it is actually done — the core idea of AI-native hiring. It also sits inside a wider picture: prompting is one of the five pillars of a rounded candidate evaluation, not a stand-alone gimmick.

Because the AI Sandbox observes real collaboration on a role-tuned task, the same underlying signal — does this person catch the model when it is confidently wrong — surfaces in whatever seat you are hiring for. You can watch a role-tuned assessment get composed to see where prompting fits per vertical, or start from our AI fluency hiring guide if you want the wider framing first.

One practical note for building the assessment: resist the urge to over-scaffold the task. If you spell out every constraint and every check the candidate should perform, you have done their prompting for them and you learn nothing. The signal lives in what they think to add and what they think to question when the brief is realistically loose — the same ambiguity they will face on the job. A good prompt-engineering task looks less like a test and more like a Tuesday morning: a real problem, the tools everyone actually uses, and enough room to reveal whether they drive the tool or the tool drives them.

Assessed this way, prompt engineering stops being a buzzword and becomes one of the most honest predictors you have of on-the-job output. Pick the role you are hiring for from the cluster above, read the deep-dive, and you will know exactly what 'good' looks like before your first candidate sits down.

Prompt engineering isn't a phrasing trick you hire for. It's judgement under an AI's confident wrongness — and it looks different in every seat at the table.