Prompting interview questions
9 questions across 3 sections, in the order you would learn them. Every answer here is one that works — but an answer you have read is not an answer you can give, so use Test yourself and say it out loud first.
A prompt is a specification
Read the section that teaches thisIf this comes up in an interview
A prompt works most of the time but occasionally returns the wrong format. What do you do?
First check whether the task and output format are fully specified, including what to do in the empty or unknown case. Then lower the temperature, since format drift is sampling variation. Then use schema-constrained output, which makes the shape a guarantee rather than a request.
Then they push further
You added a schema and it still fails on 1% of requests. Now what?
Look at the failing inputs. Check for truncation from max_tokens, for unusual inputs such as very long or empty ones, and for inputs that contain their own formatting. Then decide between fixing the prompt, validating and retrying once, or failing cleanly.
Is retrying on failure a good idea?
Once, with the validation error passed back, is usually cheap and fine. Unlimited retries hide a real problem and multiply cost. Count retries so you notice when they climb.
What gets marked up. Marked up for reaching for structured output and validation rather than more wording, and for reading the failing inputs before changing anything.
How do you stop a model inventing data during extraction?
Explicitly permit null for missing fields and state that guessing is not acceptable. Models fill gaps because the prompt demanded a value; giving them a legitimate alternative removes the pressure.
Does telling a model it is an expert improve results?
Only when the role genuinely narrows the domain, vocabulary or conventions. Piling on superlatives does nothing measurable. The gain comes from specificity, not flattery.
Examples, and when they earn their cost
Read the section that teaches thisIf this comes up in an interview
When would you use few-shot rather than zero-shot?
When the task is easier to demonstrate than describe: an unusual format, a subtle judgement, a tone. Start zero-shot, because examples cost tokens on every call, and add them when you can measure that they help.
How many examples should you use?
Usually three to five, chosen so each teaches something different. More similar examples add cost without adding information. Always include the empty or unknown case, or the model will never produce it.
What is a risk of few-shot prompting?
The model imitates the examples closely, including any inconsistency or mistake in them, and it can over-fit to their surface pattern. It can also bias the output distribution if all your examples share a property you did not intend to teach.
Reasoning, and improving a prompt honestly
Read the section that teaches thisIf this comes up in an interview
Does chain-of-thought prompting still help?
It depends on the model. On older and smaller models it gives a real improvement on multi-step tasks. Newer reasoning models do it internally, and explicit instructions can interfere. The answer is to measure it rather than assume.
How do you know a prompt change actually improved things?
Score it against a fixed set of inputs with known expected outcomes, before and after. Without a baseline you are comparing against your memory of previous outputs, which is unreliable in a predictable direction.
Then they push further
Your eval went from 80% to 82%. Is that an improvement?
Not necessarily. On a small set that is within noise. Rerun the baseline to see how much it varies on its own, and compare the two versions only on the cases where they disagree.
What gets marked up. Strong answers mention an eval run before and after, a held-out split, and awareness of noise. Weak answers describe trying a few examples by hand.
When would you split one prompt into several calls?
When it is doing several distinct jobs. Quality on each drops when they compete, and a single failure gives you no information about which step went wrong. Separate calls cost more and are far easier to debug and evaluate.
Then they push further
What does splitting cost you?
More latency, more calls to pay for, and more places for errors to creep in between steps. It is worth it when each step becomes easier to get right and to test on its own.
What gets marked up. Marked up for weighing testability and reliability against latency and cost, rather than treating chains as always better.
These are the questions for one topic. The whole question bank covers every topic on the site.