When would you use zero-shot prompting and when would you add few-shot examples?

What the interviewer wants to hear

• Zero-shot for simple, well-known tasks
• Few-shot to teach a specific format, style or label rules
• Examples should be diverse and balanced
• Examples cost tokens; measure benefit

Model answer

I start zero-shot, with clear instructions only, because modern models handle many common tasks well that way, and it keeps prompts short and cheap. I add few-shot examples when the output must follow a specific pattern that is hard to describe in words, like our brand voice, a particular summary layout, or how to label borderline support tickets. Examples show rather than tell. I choose examples carefully: they should cover different types of input, include all labels in a balanced way, and include a tricky case or two. Otherwise the model may copy accidental patterns, such as always choosing the label from the last example. Since each example adds tokens to every request, I check on the eval set that the examples actually improve results enough to justify the cost.

More easy Prompt Engineer questions

• What makes a good prompt? Walk me through how you would write one for a new task.
• How can you use prompting to reduce hallucinations?
• Your product team needs model output that software can read reliably. How do you design the prompt?
• Describe your process for improving a prompt that is giving mixed results.
• Explain temperature and top-p. How would you set them for different tasks?
• Explain retrieval-augmented generation (RAG) to a non-technical colleague. Why would we use it?
• What are tokens and context windows, and why do they matter when you design prompts?
• What is chain-of-thought prompting, and when would you use it or avoid it?
• A prompt works on your demo examples but fails for some users. How do you find out why?