What is few-shot prompting and when does it help?

30-second answer

Including a few input–output examples in the prompt. It helps most with output format, style and tricky edge cases that are hard to describe. Use diverse examples so the model generalizes rather than copying, and be aware that examples cost tokens on every request (prompt caching helps).

Try answering out loud before reading on. The walkthrough below is paced for a 40-minute interview round.

0–5 min Clarify and frame

Framing: "Few-shot examples show the model what good output looks like rather than describing it. I'll explain when they help, how to choose and format them, dynamic selection, and how they compare to other techniques."

5–15 min Core explanation

Few-shot prompting includes input → output examples in the prompt. The model infers the pattern from them: output format, style, level of detail, and how to handle edge cases.

When it helps most:

Formats and styles that are hard to describe ("write release notes like these").
Fuzzy classification boundaries (bug report vs. feature request vs. support question).
Edge cases: empty input, missing data, mixed languages, sarcasm.
Consistency across many requests.

When it's less needed:

Simple tasks strong models already do well zero-shot.
Pure format control, where structured outputs/JSON schema are more reliable.

15–25 min Deep dive: choosing and formatting examples

Choosing:

Diverse: cover the categories and edge cases you care about.
Contrastive: pairs near the decision boundary teach distinctions best.
Representative: look like real inputs (length, tone, noise).
Balanced: avoid skewing toward one label; the model picks up label frequency.
Correct: mistakes in examples are copied faithfully.
Ordered thoughtfully: models can be sensitive to order; put the most relevant last.

Formatting with clear delimiters:

<examples>
  <example>
    <input>App crashes when I upload a 2GB file.</input>
    <output>{"category": "bug", "priority": "high"}</output>
  </example>
  <example>
    <input>Could you add dark mode?</input>
    <output>{"category": "feature", "priority": "low"}</output>
  </example>
</examples>
Now classify: <input>{ticket}</input>

Dynamic few-shot: keep a labelled pool; per request, retrieve the most similar examples by embedding. Gives relevant guidance without a huge static prompt.

25–32 min Trade-offs

Technique	Strength	Cost
Zero-shot instructions	Cheap, flexible	Ambiguity on edge cases
Static few-shot	Strong format/style signal	Tokens on every request (cacheable)
Dynamic few-shot	Relevant examples per input	Retrieval infrastructure
Fine-tuning	Scales to thousands of examples, shorter prompts	Training effort, slower iteration

Pitfall: over-copying. Outputs mimic example wording or length too closely. Vary examples and state that they illustrate the pattern.

32–37 min Production example

A ticket classifier confused "billing question" with "refund request". Rewriting instructions barely helped. Adding six contrastive examples, three per class, all near the boundary, improved accuracy on the eval set substantially. Later, with 5,000 labelled tickets, the team switched to dynamic few-shot (top 4 similar examples), improving accuracy further on rare categories.

37–40 min Likely follow-ups

How many examples? Often 3–8; measure on your eval set.
Does few-shot help reasoning? Examples with worked reasoning can; for models with built-in reasoning, clear instructions often matter more.
Prompt caching? Put static examples in the cached prefix to reduce cost.

What interviewers listen for

When few-shot helps and when structured outputs are better.
Example selection principles, including contrastive and dynamic selection.

Red flags

Many near-identical examples, or examples with mistakes.