Imagine teaching someone to sort the family's incoming post. "Bills in the left tray, personal letters in the right, junk in the bin" — that's probably enough. But if your household has a rule that the electricity bill goes in a third tray because your father pays it separately, no amount of explaining beats just showing them: "this one — third tray. That one — left tray."
That is the entire zero-shot / few-shot distinction, and it's one of the two or three most-asked prompt engineering interview questions. Let's make sure you can answer it and — harder — know when to use which.
The three terms
The vocabulary is simpler than it sounds. "Shot" just means "example given inside the prompt".
| Term | Means | Looks like |
|---|---|---|
| Zero-shot | instruction only, no examples | "Classify this review as positive or negative: …" |
| One-shot | instruction + one worked example | "… Example: 'Loved it' → positive. Now: …" |
| Few-shot | instruction + several (typically 2–8) | three or four input→output pairs, then the real input |
💡 One clarification that earns marks: this is in-context learning, not training. The examples live inside this one request. The model's weights don't change, and it remembers nothing once the request ends.
Why examples work at all
Back to lesson 1's mechanism: the model continues the text it is given. When your prompt contains three input→output pairs, the most plausible continuation after the fourth input is an output of the same shape, in the same style, using the same vocabulary.
Examples don't teach the model the task — they demonstrate the pattern it should continue. That framing also predicts, correctly, when examples will and won't help: they are excellent for conveying form and quite poor at conveying facts.
When to use which
Start at the bottom rung and climb only when you have a reason. In practice:
Zero-shot works when the task is common and describable — summarise, translate, fix grammar, extract the email address. Modern models handle these without help, and adding examples just costs tokens.
Reach for examples when one of three things is true: the categories are yours (your team's definition of "P1", not the world's); the output shape is unusual and hard to describe; or there's a boundary case the model keeps getting wrong and you want to demonstrate the rule rather than argue it in prose.
How to choose examples
This is where the difference between a passable and an excellent answer shows up. Four rules:
- Cover the classes. If you have three categories, show all three. Examples that only demonstrate two make the third feel unlikely.
- Include a boundary case, not just easy ones. The examples that teach the most are the ones sitting right on the line you keep losing.
- Be perfectly consistent. Same format, same punctuation, same capitalisation in every example. The model copies the pattern including your inconsistencies.
- Watch the order. If all your positive examples come first and negatives last, some models pick up the ordering as part of the pattern. Mix them.
Label each message with the department that should handle it.
Departments: billing, technical, logistics.
"My card was charged twice" -> billing
"The app crashes when I open orders" -> technical
"Package shows delivered but nothing came" -> logistics
"Refund not received after 10 days" -> billing
"Delivery boy asked for extra money" -> logistics
"I was charged for a plan I cancelled" ->Result
Note the third and fifth examples: both are delivery complaints that a careless reader might file as billing. They're there on purpose.
Wait — can examples make it worse?
Yes, in three specific ways, and interviewers love this follow-up.
Format lock-in. If all your examples are one-line answers, you'll get a one-line answer for the input that genuinely needed a paragraph. The pattern was copied too faithfully.
Skewed priors. Four "negative" examples and one "positive" nudges the model toward negative on genuinely ambiguous inputs. Your example distribution becomes a prior.
Copying instead of reasoning. Give an example too close to the real input and the model may reuse its answer with details swapped, rather than working the case out.
🎯 Selection-round radar: after "what is few-shot prompting?", the differentiating follow-up is "when would you not use it?". Have the answer ready: when the task is common enough for zero-shot, when the examples would eat context you need for actual data, and when the output should vary in length or shape — because examples lock the shape in.
How many examples?
The honest answer is "measure it", but the practical starting points are well established: 2–5 for classification with clear categories, 3–8 when demonstrating a format or tone, and past roughly ten you are usually in diminishing returns — paying real tokens per request for little movement.
If ten well-chosen examples still aren't enough, that is a signal, not a reason for an eleventh. Either the task is genuinely ambiguous (write a clearer definition), or you've outgrown prompting.
When few-shot isn't enough
The rung above few-shot is fine-tuning — training on hundreds or thousands of examples so the behaviour is baked in and costs no prompt tokens at all. It is worth it when few-shot has plateaued, you have the labelled data, and the volume justifies the setup.
And there's a third direction people confuse with this one: if the model is failing because it lacks facts rather than because it misunderstands the task, neither examples nor fine-tuning is the answer — you need retrieval. Examples fix behaviour; retrieval fixes knowledge.
Common mistakes
- Calling in-context examples "training" — the weights never change.
- Showing only easy examples, so the boundary the model keeps missing is never demonstrated.
- Inconsistent formatting across examples — the model copies the inconsistency.
- An unbalanced mix of labels, which silently biases ambiguous inputs.
- Adding examples to a task that zero-shot already handled.
- Using examples to supply facts the model needs; that's a retrieval problem.
Quick recap
| Concept | One-liner |
|---|---|
| Zero / one / few-shot | zero, one, or several worked examples inside the prompt |
| In-context learning | examples demonstrate a pattern for this request only; no weights change |
| Use examples when | the labels are yours, the format is unusual, or a boundary keeps failing |
| Choosing them | cover all classes, include boundaries, stay consistent, mix the order |
| How they hurt | format lock-in, skewed priors, copying instead of reasoning |
| Next rung | fine-tuning for behaviour at volume; retrieval if the gap is facts |
Practice Zone — PYQs from real selection rounds
Six MCQs, then two example-design tasks — including one where the examples are the bug.
When should you move from zero-shot to few-shot prompting?
Asked in
What is the most common mistake in few-shot example selection?
Asked in
Do few-shot examples change the model's weights?
Asked in
How many few-shot examples is usually a sensible starting point?
Asked in
Your few-shot prompt classifies well but occasionally outputs an explanation instead of just the label. Most likely cause?
Asked in
What is 'dynamic few-shot' (example selection at runtime)?
Asked in
Hands-on tasks:
Build a few-shot prompt that extracts {product, issue, urgency} from Indian customer complaints, including one Hinglish example and one with a missing field.
Asked in
A colleague starts every new task with a 10-example few-shot prompt. Explain the cost and the better workflow.
Asked in
FAQ
Do the examples have to be real?
They have to be correct. Invented examples are fine and often better, because you can construct exactly the boundary case you need. What breaks things is an example with a wrong label — the model will faithfully reproduce your mistake.
Where do examples go — before or after the instruction?
Instruction first, then examples, then the real input. The instruction frames what the examples are demonstrating; the other way round, the model reads several pairs without knowing what to look for.
Is few-shot prompting the same as RAG?
No, and mixing them up is a common interview slip. Few-shot supplies examples of the task, chosen by you and usually fixed. RAG supplies facts about the question, fetched at runtime and different every time (RAG lesson 1).
Next lesson: making the model show its working — and why that sometimes doubles accuracy — Lesson 4: Chain-of-Thought Prompting →