Prompt Engineering interview questions
Prompt Engineering questions a AI engineer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
What is the difference between zero-shot and few-shot prompting, and when do you add examples?
The strongest answer: Zero-shot is instructions only; few-shot adds a few worked input–output examples. I add examples when instructions alone miss the format or the judgement, and keep them varied because the model imitates them closely
Why it works: Exactly — start zero-shot, add examples when the output shape or the borderline calls are off, and vary them so the model learns the pattern rather than one example’s surface.
- Zero-shot: instructions. Few-shot: plus examples.
- Add examples when instructions fall short.
- Few, varied and correct.
- No real personal data in examples.
What belongs in the system prompt, and what belongs in the user message?
The strongest answer: System: the application’s standing rules — role, task, constraints, output format — written by us. User message: this turn’s input, which we treat as data. No secrets in either, because system prompts can be coaxed out
Why it works: Right — stable rules from the developer in one place, per-turn input in the other. Models are trained to give system instructions more weight, but it is not a vault.
- System: standing rules from the developer.
- User: this turn’s input, as data.
- Task, constraints, format beat persona.
- Never put secrets in a prompt.
For a week the model received “Summarise the ticket for [customer_name]” with the placeholder unfilled, and nobody noticed until a customer did.
How should prompt templates be handled so this cannot happen quietly?
The strongest answer: Templates live in the repo with named variables and one render function that fails loudly on a missing value. Rendering is unit-tested, and the final prompt is logged so we can read what was sent
Why it works: Exactly — a prompt template is code: strict rendering, tests, and sight of the rendered result. A silent empty variable is a bug class you can close.
- Treat prompt templates as code.
- Render strictly; fail on missing variables.
- Unit-test the rendering.
- Log the rendered prompt, personal data masked.
What is prompt injection, and why can you not fix it with a better-worded prompt?
The strongest answer: Content meant as data — a web page, a file, a user message — carries instructions and the model follows them. Both arrive in one channel, so wording lowers the odds but draws no hard line
Why it works: Exactly — no parser separates code from data here. Delimiters and clear rules help, and what the output is allowed to do gets decided in code, not in the prompt.
- Instructions and data share one channel.
- Wording reduces, never eliminates.
- Fence untrusted text; label it as data.
- Limit what the output can do.
One large prompt reads a support email, extracts the order details, classifies the issue, decides whether a refund applies and writes the reply. Quality is uneven and nobody can tell which part fails.
What do you change?
The strongest answer: Split it into a chain — extract, classify, draft — each step one job with an output I can validate and evaluate separately. The refund decision moves into code. The price is more calls and latency
Why it works: Exactly — decomposition buys visibility: each step gets its own eval, its own model size, and code in between. And a policy decision does not belong in a prompt at all.
- One step, one job, one checkable output.
- Validate between steps.
- Business rules live in code.
- Name the cost: calls and latency.
A production prompt has grown forty lines of “IMPORTANT: never…”, each added after an incident. Every new line now breaks some older behaviour.
How do you get out of this?
The strongest answer: Turn every past incident into a regression case first. Then rewrite the prompt from the task description — rules stated once, with reasons, conflicts resolved — and ship only when the whole set passes
Why it works: Exactly — the incidents are your test suite. With them in place a rewrite is safe, and contradictions between patches become visible instead of being settled by emphasis.
- Incidents become regression cases first.
- Rewrite from the task, not the patches.
- State each rule once, with its reason.
- Ship only when the full set passes.
The company moves to a different model provider to cut cost. The prompts are copied over unchanged and quality drops on several features. A manager asks why “the same prompt” behaves differently.
What is your explanation, and how do you run model migrations from now on?
The strongest answer: Prompts are tuned to one model’s habits, so the wording does not port. The task spec and eval set do: every model change means re-running evals and re-tuning per feature, with that time budgeted
Why it works: Exactly — workarounds written for one model can hurt another. Treat the prompt as coupled to the model, and the evals as the contract that survives the move.
- Prompt wording is coupled to the model.
- Spec and evals are the portable assets.
- Re-run evals on every model change.
- Budget re-tuning into the migration.
After an incident in which the assistant offered a customer a refund above the allowed limit, the product owner asks you to “just add a line to the prompt” so it never happens again.
What is your answer?
The strongest answer: I add the line and say plainly it is guidance, not a guarantee. Anything that must never happen — limits, permissions, who sees what — is enforced in code around the model, where it can be tested
Why it works: Exactly — a prompt shapes behaviour; it does not enforce. The senior move is telling the owner which kind of rule this is, and putting the limit where a test can prove it.
- Prompts guide; code enforces.
- Must-never rules live outside the model.
- Say which kind of control it is.
- Test the hard limit in code.