Prompt engineering interview questions

Interviews for this title have moved a long way from phrasing tricks. Modern models follow instructions well, so rewording is no longer where the leverage is — deciding what goes into the context is.

Expect the first real question to establish which kind of candidate you are. Shown a failing case, do you reach for a rewrite or for a measurement? Interviewers are listening for the second, and the difference is audible within a sentence.

It is worth knowing that many of these postings are AI engineering roles with a legacy title attached. Reading the responsibilities rather than the heading tells you whether to prepare for retrieval and evaluation or for something narrower like content operations.

You will be asked how you would structure the input to a model for a real task. Weak answers describe an instruction. Strong ones describe an assembled document: system instructions, retrieved material, history, tool results, and what gets dropped when the budget runs out.

Follow-ups probe the trade-offs. Why not include everything, given large context windows? A good answer covers cost, latency and the fact that accuracy degrades when the relevant fact is buried among irrelevant ones.

Ordering is the detail that separates answers. Instructions placed after a long block of retrieved text behave differently from the same instructions placed before it, and mentioning that you position what matters at the edges rather than the middle signals someone who has measured rather than read.

• What goes into the context, in what order, and why that order?
• What do you evict first when it will not all fit?
• How do you tell a retrieval failure from a generation failure?
• When is a larger context window the wrong answer?

Expect "how do you know your prompt is better". This is the single highest-signal question in the interview, because a candidate who has shipped has an answer and one who has only experimented does not.

A strong answer describes a versioned set of real cases, deterministic checks where a property can be stated precisely, model-graded scoring where it cannot, and a run on every change. Mentioning that you calibrate the grader against human judgement marks you out immediately.

The most persuasive version carries a number. Saying that a change you were confident about scored worse, and that you kept the old version because of it, demonstrates the whole discipline in one sentence and is very hard to fabricate.

Practical questions about getting parseable output come up constantly, because it is where hobby projects break in production. Schema enforcement, what to do with a malformed response, and whether to retry or repair.

The answer that shows experience is that you validate rather than trust, and that a retry loop needs a ceiling. "Retry until it parses" is a plausible answer that becomes an unbounded bill the first time a model gets stuck.

Add that a schema is a correctness boundary rather than a convenience. Validating into typed data means a malformed response fails at the edge with something you can retry deliberately, instead of a stray field surfacing three layers downstream as a confusing bug.

Prompt injection now appears in most interviews for this role. The answer that lands treats it architecturally: the model can be talked into anything, so the control is what the surrounding system permits, not what the prompt requests.

Being able to separate direct from indirect injection, and to explain why the indirect kind is harder because the payload arrives through a trusted-looking channel, distinguishes you from candidates who have read one article about jailbreaks.

Expect a follow-up asking what you would do if instruction hardening is all that is available. The honest answer is that you would reduce what the component can reach instead, and if that is impossible, that the feature needs a human in the path — not that you would write a better instruction.

Many loops now include a live task: here is a corpus and a failing question, improve it. What is assessed is your first move, and the first move that scores is inspecting what the model was actually given.

Candidates who immediately start editing the instruction are demonstrating the habit the role has moved away from. Candidates who ask to see the retrieved chunks, notice the answer was not among them, and fix the retrieval are demonstrating the one it moved towards.

Say what you would measure before and after, even if the exercise is too short to run it. Naming the check is most of the signal, and it costs one sentence.

Build one small system and measure it. Thirty questions with known answers, a baseline score, then changes with the effect of each recorded. That single exercise answers nearly every question above with a specific number instead of an opinion.

Bring one failure you diagnosed. Describing a case where the model looked wrong and the real cause was retrieval — and how you found that — is the most convincing thing you can say in this interview.

Also prepare for the cost question, which candidates from this background most often neglect. Knowing what drives tokens in your own project, and one change that reduced it without hurting the score, covers the gap that most frequently separates this title from an AI engineering offer.