Early prompt work was full of tricks: telling the model it was an expert, repeating an instruction in capitals, promising a tip for a better answer. Newer models need far less of that, and provider features such as structured outputs and prompt caching have replaced a lot of the coaxing. What has grown instead is the unglamorous part of the job: choosing what the model sees, measuring whether a change helped, and following an assistant through several tool calls to find where it went wrong. The prompt engineer skills that hold their value now look more like test design and clear technical writing than like wordplay.
This post sets out eight skills with a way to check each, the working habits that matter around them, what has gained and lost importance, a matrix by level, and how to run a hiring process when the title itself is young and CVs are hard to compare.
Core skills for a prompt engineer
Turning a vague request into a specification
A good system prompt reads like a brief to a capable new colleague: who the reader is, what done looks like, what to do when information is missing and what must never appear. Strong candidates write plainly and remove instructions that conflict. How to check it: give them the instruction “summarise this call helpfully” and ask what they need to know before improving it. Good ones ask who reads the summary, what decision it feeds and what a harmful omission would be, then write a tighter version.
Context design
Much of the work is now deciding what goes into the model’s context and in what order: retrieved passages, conversation history, tool results, examples and policy text. More context can make answers worse as well as costlier, and many providers discount a stable repeated prefix, so structure affects the bill. How to check it: describe an insurance assistant that sends the full policy document and the whole chat history on every turn. Ask what they would cut, summarise or fetch on demand, and how they would confirm that quality held.
Building a test set worth trusting
Test sets go wrong in quiet ways. Sampling recent logs gives mostly easy questions, and a prompt tuned repeatedly against one set simply learns that set. How to check it: say production logs are dominated by simple balance enquiries, with rare but serious complaints about fraud. Ask how they would sample so those rare cases are represented, and how they would stop the prompt being overfitted. Look for deliberate oversampling of risky categories and a held-out set that is touched only for final decisions.
Choosing a scoring method
Not everything needs a human reader. Exact checks suit extraction fields, code-based checks suit format rules, and a model acting as judge can scale review of tone or completeness, provided someone has tested the judge. How to check it: ask how they would score a summarisation task across a very large batch of outputs on a limited budget. A strong answer mixes cheap automatic checks with a sample of human review, and compares the model judge against human labels before relying on it.
Reading small differences honestly
Output varies from run to run, so a small rise in an average score may be noise. Careful people compare results case by case and look at which examples flipped, because one fixed category can hide one newly broken. How to check it: say a new prompt scores slightly higher overall on two hundred cases, and ask whether they would ship it. Good answers ask to see the cases that got worse, how severe those are, and whether repeating the run gives the same result.
Structured outputs and tool descriptions
Schemas and tool definitions are prompts too. A required field the document may not contain invites the model to invent a value, and two tools with overlapping descriptions lead to wrong calls. How to check it: show an extraction schema where the GST number is mandatory, then give an invoice without one. Ask what the model is likely to do and how they would redesign the schema. Look for a nullable field or an explicit unknown value, plus validation in code after the model responds.
Indian languages and mixed input
Many Indian users write in Hinglish, switch script mid-sentence or use English terms inside a regional sentence. English-only test sets miss all of this, and native reviewers are needed to judge tone and formality. How to check it: show an assistant whose evaluation set is entirely in English, then tell them a large share of real messages are in romanised Hindi. Ask what they would change in testing, who would review the results and whether replies should follow the user’s language.
Safety testing and over-refusal
Safety work runs in both directions. An assistant must not leak data or follow malicious instructions, and it also must not refuse ordinary requests after a heavy-handed safety line is added. Secrets do not belong in a system prompt, since it can often be drawn out. How to check it: describe an HR assistant that can read payroll documents, and ask for a short adversarial test plan. Then say it has started refusing routine leave questions, and ask how they would find the balance. Good candidates separate what the prompt can encourage from what access controls must enforce.
Working skills that separate good from average
- Drawing out expert judgement. A claims handler or lawyer knows a bad answer on sight but may struggle to say why. Strong prompt engineers ask for examples, turn them into written criteria and go back to confirm the criteria match how the expert actually decides.
- Reporting uncertainty straight. They tell a product manager what the evaluation does not cover, which failures remain and how serious those are, instead of offering one flattering score.
- Keeping a record of why. A long prompt collects lines nobody dares delete. Good practitioners note what failure each instruction fixed, so the next person can remove it safely when a new model no longer needs it.
- Recommending against an LLM. Sometimes a lookup table, a rule or a small classifier does the job at lower cost and with fewer errors. People who say so openly are protecting the project.
Where the skill set has moved in 2026
Mattering more. Agents have changed the unit of evaluation from one answer to a whole sequence of steps, so reading traces and scoring tool choice now sit alongside judging final text. Tools such as LangSmith and Langfuse make that practical, and candidates should be comfortable using something similar. Providers retire models on published schedules, so migration testing is routine maintenance. Cost per completed task matters more than token price as teams route simple work to cheaper models. Privacy has also moved closer to the role: India’s Digital Personal Data Protection Act is a good reason to keep personal data out of prompts and logs wherever possible.
Mattering less. Role-play openers and magic phrases rarely change much on current models, and prompt collections sold as shortcuts are worth little. Coaxing valid JSON through pleading instructions has largely given way to structured output features.
Prompt engineer skills matrix by level
| Skill area | Junior | Mid-level | Senior |
|---|---|---|---|
| Instructions | Edits prompts within a set pattern | Writes clear system prompts from scratch | Sets prompt standards across products |
| Context design | Understands tokens and limits | Chooses what enters the context and when | Shapes context architecture with engineers |
| Test sets | Labels outputs against a rubric | Builds sampled sets with held-out cases | Owns evaluation strategy company-wide |
| Scoring | Runs existing checks | Combines automatic checks and human review | Validates model judges and release gates |
| Outputs and tools | Follows existing schemas | Designs schemas and tool descriptions | Reviews agent behaviour across long traces |
| Safety | Flags unsafe outputs | Writes adversarial test cases | Agrees controls with security owners |
| Stakeholders | Takes direction from reviewers | Turns expert judgement into criteria | Advises leaders on whether to use an LLM |
How to assess prompt engineering skill in a hiring process
Few candidates have long histories in this title, so judge recorded evidence over tenure. The prompt engineer job description sets the scope, and these steps test whether someone can do the work behind it.
- Ask for a change log. A record of prompt versions, what each fixed and how it scored, with client details removed, is far more telling than a folder of finished prompts.
- Run a failure triage. Give thirty failed outputs from one assistant and ask the candidate to group them by cause and say what to fix first.
- Inherit a messy prompt. Hand over a long system prompt with contradictory rules. Ask what they would remove and how they would prove nothing got worse. Rewriting from scratch with no evidence plan is a poor sign.
- Bring in a domain reviewer. Let a support lead or subject expert join one session. Candidates who listen and turn that person’s comments into criteria will work well with your reviewers.
Red flags on a CV: accuracy claims with no dataset or method behind them; lists of model names with no product attached; experience that is only chat use for marketing copy; prompt packs offered as portfolio work; and no mention of a change that failed.
Frequently asked questions
Can a content writer become a prompt engineer?
Some can, since precise writing is central to the job. The gap is usually measurement: building test sets, reading results and working with enough Python or tooling to run them. A writer who has built an evaluated project is a stronger candidate than a coder with no ear for language.
Which model providers should candidates have used?
Experience on your provider helps but should not be a hard filter. Skills carry across, although each model family responds differently, so ask how they adapt a prompt when moving between models.
How large should a first evaluation set be?
Start with a few dozen real cases covering the main tasks and the known failures, then grow it from production mistakes. A small set you can review by hand beats a large one nobody reads.
Will better models remove the need for these skills?
Better models reduce the need for tricks, but someone still has to define what good means for your business and prove that a change meets it. That work tends to survive as a part of AI engineering or quality roles, even where the title disappears.
Once you know the gap is quality, you can hire prompt engineers in India through Zilo AI on contract, contract-to-hire or permanent terms. If the brief turns out to need an application built as well, our IT talent hiring page also covers generative AI and AI product engineers. Send us a note on your product and where its answers fall short.