What prompt-engineering interviews actually test
The title “prompt engineer” is consolidating into broader AI roles, but the skill it names is in demand everywhere. Interviews that probe prompting are really testing three things: can you get reliable output from a model under constraints, can you explain why a technique works and when it does not, and can you treat prompting as measurable engineering rather than trial and error. Candidates who fail usually do so not because their prompts are bad but because they cannot articulate a process or prove an outcome. This guide covers the live exercise, the technique questions, the portfolio, and the impact story.
The live prompting exercise
You will be handed a concrete task and a model, and asked to make it work while someone watches. The task is usually one of a few archetypes: extract structured fields from messy text, classify or route inputs, transform content into a format, or generate copy in a constrained voice. The interviewer cares less about your first prompt than about your loop. Strong candidates start simple, run a few representative inputs including deliberate edge cases, notice where the output breaks, and then add exactly the constraint or example that fixes it.
Narrate as you work. Say “the model is over-extracting here, so I will add a negative example and require it to output an empty field when unsure.” Reach for techniques deliberately: a couple of few-shot examples to pin format, an explicit output schema, a role to set domain context, step decomposition for multi-part tasks. Show that you test rather than hope. If you copy a clever prompt from memory and it works, that is luck; if you iterate visibly toward a robust one, that is skill, and it is what gets you hired.
Techniques and the impact story
Be fluent in the core techniques and, for each, know what it does, when it helps, and its cost. Few-shot pins format and behaviour with examples but spends tokens. Chain-of-thought improves reasoning on multi-step problems at the cost of latency and length. Role/persona sets context and tone. Structured output (schemas, JSON constraints) makes results parseable. Decomposition splits a hard task into reliable smaller calls. Self-consistency or verification trades extra calls for accuracy. The mark of seniority is knowing when not to use one — chain-of-thought on a trivial classification just burns tokens.
The portfolio and impact story tie it together. Document a few real problems you solved: the original prompt, the failure modes, the iterations, and the measured result against an evaluation set. The most persuasive sentence you can say in the interview is a number: “I built a test set of 200 examples, raised extraction accuracy from 71% to 94%, and cut tokens 30% by removing redundant instructions.” That single line communicates that you treat prompting as engineering — you measure, you iterate, you control cost — which is exactly what the role is for. Prepare two or three such stories, lead with the metric, and you will outshine candidates who only have clever prompts and no proof they work.