Prompt Engineering
Prompting is the cheapest, fastest way to steer an LLM: clear instructions, few-shot examples, explicit output format, and the right context. It is the first technique to try before reaching for RAG or fine-tuning, and in production it means versioned, tested prompt templates with separated instructions and untrusted data, not ad-hoc strings. Applied-AI interviews probe it because most LLM features ship on prompting alone, and because sloppy prompts are a top source of unreliability and injection risk.
TL;DR: Prompting steers a model with instructions, examples, and context rather than training. The high-leverage moves are clear task instructions, a few worked examples (few-shot), an explicit output format, and supplying the right context. It is the first thing to try because it is the cheapest and fastest to iterate, and most features ship on it. In production, prompts are versioned, tested templates with system instructions clearly separated from untrusted user/retrieved content, not strings glued together at call time.
The levers that actually move quality
A handful of techniques do most of the work:
- Clear, specific instructions. State the task, constraints, and what "good" looks like. Vague prompts get vague output.
- Few-shot examples. Show two or three worked input/output pairs. The model learns the pattern and format from demonstrations (in-context learning is why this works) without any training.
- Explicit output format. Ask for JSON, a table, or a fixed structure, and the model conforms far more reliably (enforce it hard with constrained decoding when valid output is non-negotiable).
- Relevant context. Give the model the material it needs (retrieved passages, the user's data). This is where prompting meets RAG.
- Role and tone framing, and decomposition (break a complex task into steps or chained prompts).
The order of impact is not symmetric. On a support-ticket classifier I have watched go from a 0-shot one-liner ("classify this ticket") to a structured prompt, the gains stacked roughly like this:
| Change | What it fixed | Rough accuracy |
|---|---|---|
| 0-shot vague instruction | nothing, baseline | ~62% |
| + label definitions and the closed set of classes | model stopped inventing categories | ~78% |
| + 3 few-shot examples (one near a boundary) | disambiguated the two classes it kept confusing | ~88% |
| + "return JSON {label, confidence}" | killed prose preambles that broke the parser | ~88%, but 100% parseable |
Two lessons fall out. First, pinning the label set and format buys reliability the eval cares about even when raw accuracy plateaus: a 94% accurate model that returns un-parseable text is 0% useful downstream. Second, the highest-value few-shot example is the one near a decision boundary, not three easy cases that all look the same.
Prompting in production is not ad-hoc
A demo prompt is a string; a production prompt is an engineered artifact:
- Versioned templates. Prompts are code: stored, versioned, and changed deliberately, because a small wording change can shift behavior across every request.
- Tested against examples. Evaluate prompt changes on a held-out set (the same discipline as model changes), so a "tweak" does not silently regress quality. Frameworks like DSPy even optimize prompts against a metric automatically. A wording change that helps the median case can quietly tank a tail class, which only a held-out set catches.
- Instructions separated from data. The system instructions and the untrusted user/retrieved content must be clearly delimited, because instructions hidden in that content can hijack the model (see prompt injection). Never treat retrieved text as instructions.
First, not last, resort
Prompting is the cheapest, fastest technique and should be the first thing you try: no training, no infra, instant iteration. Many problems are fully solved here. Only when prompting plateaus do you reach for retrieval (knowledge gaps) or fine-tuning (behavior gaps), the prompting vs RAG vs fine-tuning decision.
Why interviewers probe this
Most shipped LLM features are "just" good prompting, so the skill is undervalued and over-mystified at once. A strong answer names the concrete levers (instructions, few-shot, format, context), treats prompts as versioned, tested artifacts rather than strings, and flags the security seam (separate instructions from untrusted content). That shows you can ship reliably on prompting before escalating to heavier tools.
Common misconceptions
- "Prompt engineering is guessing magic words." The levers are concrete: clear instructions, examples, format, and context.
- "Prompts do not need testing." A wording change can regress every request; evaluate prompt changes like model changes.
- "Fine-tuning is usually the answer." Prompting (then RAG) is cheaper and faster; fine-tune last.
- "It is safe to drop user/retrieved text into the prompt." That is the injection vector; separate instructions from untrusted content.
Key takeaways
- Prompting steers a model with instructions, few-shot examples, explicit format, and context, the cheapest, fastest lever.
- Treat prompts as versioned, tested templates, not ad-hoc strings; a small change can shift behavior broadly.
- Keep system instructions separate from untrusted user/retrieved content to limit prompt injection.
- Try prompting first; escalate to RAG (knowledge) or fine-tuning (behavior) only when it plateaus.
Check yourself before an interviewer does. Answer from memory first.
You're adding few-shot examples to a classifier prompt. Which one example buys the most accuracy?