Prompt Engineering Interview Questions

A curated set of prompt engineering interview questions covering the techniques that come up when discussing how to reliably get useful output from an LLM in production.

Fundamentals#

Q: What's the difference between zero-shot and few-shot prompting, and when would you use each? Zero-shot gives the model only an instruction, with no examples — fine for straightforward, well-understood tasks. Few-shot includes a handful of worked examples before the actual request, which helps when the task has a specific format, edge-case handling, or judgment call that's easier to demonstrate than to fully describe in words — for example, getting a sentiment classifier to consistently pick exactly one of three fixed labels even on ambiguous, mixed-sentiment input.

Q: Why does chain-of-thought prompting improve accuracy on some tasks? It gives the model room to work through a problem in explicit, smaller steps instead of having to combine multiple reasoning steps silently in one leap. Each intermediate step only has to be locally correct, which reduces the chance of a compounding error, and makes mistakes easier to spot in the output. It helps most on genuinely multi-step problems (arithmetic, multi-part logic) and does little for tasks that are already a single lookup or simple transformation.

Q: How do you get an LLM to reliably return valid, parseable structured output like JSON? Specify the exact schema (field names and allowed values) rather than describing the format loosely, and explicitly instruct the model to return only the structured data with no additional commentary — without that, models often prepend a conversational preamble that breaks naive parsing. In production, treat the model's output as untrusted input: parse it defensively and validate it against the actual schema afterward, rather than assuming it will always conform.

Q: What's the difference between a system prompt and a user prompt? The system prompt sets standing behavior for the entire conversation — persona, scope, constraints, output defaults — and is typically set once by the application, not the end user. The user prompt is the specific request for a given turn. Keeping standing rules in the system prompt and per-turn requests in the user prompt keeps the conversation's behavior consistent and makes the whole thing much easier to maintain as an application grows.

Q: What is function/tool calling, and why is it useful? It's a pattern where you describe available functions (name, description, expected parameters) to the model, and instead of answering directly, the model returns a structured request naming which function to call and with what arguments — which your application code then actually executes. It's useful because it lets a model take real, permissioned actions (looking up live data, executing a calculation, calling an internal API) without ever directly touching the underlying systems itself; your code stays in full control of what actually happens.

Security#

Q: What's the difference between direct and indirect prompt injection? Direct injection is a user directly typing instructions intended to override the system prompt, in their own message. Indirect injection is more dangerous in practice: the malicious instructions are embedded in content the application retrieves and feeds to the model on the user's behalf — a webpage an agent browses, a document in a RAG store — so the end user never sees or knowingly participates in the attack; they just asked for something ordinary like "summarize this page."

Q: What's the most effective structural defense against prompt injection? Treating all external or retrieved content as untrusted data rather than as instructions, and making that separation explicit and structural — clear delimiters around untrusted text, combined with an explicit system-prompt instruction that content inside those delimiters should never be treated as a command to follow. Combined with least-privilege tool access for any agent, so a successful injection has as little to actually exploit as possible.

Systematic evaluation and multi-modal prompting#

Q: Why is a handful of manual test prompts not a sufficient way to evaluate a prompt before shipping it? LLM output is non-deterministic and sensitive to small input variations, so a handful of manually-checked examples doesn't represent the real range of inputs a prompt will see in production, and gives no reliable way to notice a regression on cases you didn't happen to re-check. A proper evaluation dataset — including edge cases and every past real failure — combined with automated scoring lets a prompt change be validated systematically rather than by impression.

Q: Why should prompts be version-controlled the same way application code is? A prompt driving real application behavior is functionally part of the application's logic — changing it changes what the system does. Without version history, there's no way to know which prompt version produced a given past output, no clean way to roll back a regression, and no reliable way to attribute a quality change to a specific edit; treating prompts as versioned artifacts gives all of that back.

Q: What's a key limitation to keep in mind when prompting a model with an image instead of text? The model can still hallucinate about an image's content the same way it can about text — describing a detail that isn't actually present or misreading fine text — and this risk increases with low resolution, small text, or cluttered layouts. Being as specific about the visual task as you would for a text task (naming an exact schema for extraction, for instance) measurably improves reliability, the same discipline that improves text-only prompts.