Cheat sheet · LLMs & Agents

Prompt engineering cheat sheet

The key ideas on one page — plus common pitfalls and interview tips. Skim it before an interview, or print it for revision.

Prompt engineering is the practice of structuring inputs, context, and decoding controls to steer an LLM toward reliable, well-formatted outputs. This sheet covers core techniques, structured/tool-augmented prompting, evaluation, and the trade-offs interviewers expect you to reason about in 2026 (native reasoning models, structured outputs, prompt caching, and automated optimizers).

Core Principles & Anatomy of a Prompt

A prompt has roles (system / user / assistant) and components: instruction, context, input data, output format, and optional few-shot examples. The system message sets persona, constraints, and global rules; keep stable instructions there.
Be specific and declarative: state the task, audience, format, length, and what to do under uncertainty. Ambiguity is the #1 cause of bad outputs.
Put long, static context (docs, schema) near the top or in a cached prefix; put the actual question/instruction last. Models attend strongly to the beginning and end (primacy + recency); middle content can be 'lost in the middle'. Newer long-context models reduce but do not eliminate this effect, so still retrieve only what is needed.
Use delimiters (XML tags, triple backticks, headers) to separate instructions from data — this reduces prompt injection and parsing errors. Claude in particular responds well to XML-style tags like <document> and <instructions>.
Prefer positive, concrete instructions ('respond in JSON only') over negative ones ('do not add prose'); give the model a target rather than a prohibition.
Iterate empirically: prompt engineering is an evaluation-driven loop, not a one-shot art. Change one variable at a time and measure against a fixed test set.

Reasoning & Decomposition Techniques

Zero-shot CoT: append 'Let's think step by step' to elicit intermediate reasoning; improves arithmetic/logic on non-reasoning models but adds latency and tokens.
Few-shot / in-context learning: include 2-8 demonstrations of input->output. Quality, diversity, and ordering of examples matter more than count; balanced labels prevent the model from copying a skewed prior.
Self-consistency: sample N reasoning chains at temperature>0 and take the majority-vote answer — trades cost for accuracy on reasoning tasks. Use an odd N to avoid ties.
Decomposition: split complex tasks into sub-prompts (prompt chaining) or use least-to-most prompting; each step is easier to verify and debug than one mega-prompt.
ReAct: interleave Reasoning + Acting (tool calls) in a 'Thought -> Action -> Observation' loop — the basis of most agents.
Modern reasoning / extended-thinking models do internal CoT natively; with these, rigid step-by-step prompting can hurt — give the goal and constraints, not a fixed procedure. Reserve explicit CoT for non-reasoning models.
Role/expert priming ('You are a senior tax attorney') can sharpen domain tone and vocabulary but does not add knowledge the model lacks.

Structured Output, Tools & Grounding

For machine-readable output, use native structured outputs / JSON mode or function/tool calling with a JSON Schema instead of asking for JSON in free text — it constrains decoding and removes parsing failures. Many providers support strict schema enforcement (e.g. additionalProperties:false + required) that guarantees valid output.
Provide the schema explicitly and one example object; validate the result (e.g. pydantic) and add a repair/retry step on validation failure.
Tool/function calling: you declare tools with a name, description, and parameter schema; the model emits a structured call, your code executes it and returns the result for the model to continue. Tool descriptions are prompts — state WHEN to call the tool, not just what it does.
RAG grounding: inject retrieved passages and instruct 'answer only from the provided context; if it is not there, say you don't know' to curb hallucination and enable citations.
Prompt caching: mark large static prefixes (system instructions, schemas, long docs) as cacheable to cut cost/latency on repeated calls. Caching is a prefix match, so any byte change in the prefix invalidates the cache — keep stable content first and the variable part last.
Keep few-shot examples and tool schemas in the cached prefix; let only the user query vary per request.

Decoding Controls & Determinism

Temperature divides the logits before the softmax: p_i = exp(z_i / T) / sum_j exp(z_j / T). As T->0 the distribution collapses to argmax (greedy); higher T flattens it for more diversity.
top_p (nucleus): sample only from the smallest set of tokens whose cumulative probability >= p. top_k: restrict to the k highest-probability tokens. Tune one of temperature or top_p, not both aggressively.
Use low temperature (0-0.3) for extraction, classification, code, and factual QA; higher (0.7-1.0) for brainstorming and creative writing.
frequency_penalty / presence_penalty reduce repetition; max_tokens caps output (set it high enough to avoid truncated JSON); stop sequences cut generation cleanly.
Even at T=0 outputs are not guaranteed bit-identical (floating-point, hardware, and batching nondeterminism); use a seed where supported but do not assume reproducibility.
Some newer reasoning/extended-thinking models remove sampling params (temperature/top_p/top_k) entirely and steer behavior via prompting and an effort/thinking setting instead — check the model's API before passing them.
Control output length and structure via the prompt ('<= 3 sentences') and parameters together for reliability.

Evaluation, Iteration & Safety

Build an eval set before optimizing: golden examples with expected outputs + metrics (exact-match, F1, rubric scores). Treat prompts like code under version control.
LLM-as-judge: use a separate model with a rubric to score open-ended outputs at scale; mitigate biases (position, verbosity, self-preference) by randomizing order, using pairwise comparison, and calibrating against human labels.
Defend against prompt injection: never trust retrieved/user content as instructions; separate trusted instructions from untrusted data with delimiters, apply least-privilege on tools, and validate tool inputs and outputs.
Reduce hallucination: grounding + 'cite sources' + 'say I don't know' + lower temperature; verify critical claims with a second pass or external check.
Optimize the prompt before reaching for fine-tuning: prompting + few-shot + RAG often suffices and is cheaper/faster to change. Fine-tune when you need consistent format/style at scale or to cut prompt length.
Automated prompt optimization (e.g. DSPy, meta-prompting) compiles/optimizes prompts against a metric — useful once you have an eval harness and want to stop hand-tuning.
Track cost = input_tokens * in_price + output_tokens * out_price; long few-shot and CoT inflate this, so balance accuracy against token spend (prompt caching cuts the repeated-prefix cost).

Common pitfalls

Asking for JSON in prose instead of using structured outputs / tool calling, then fighting parse errors — constrain decoding at the API level and validate.
Stuffing huge context and assuming the model reads it all — middle content gets 'lost'; put critical info at the start/end and retrieve only what's needed.
Over-prompting reasoning models with rigid step-by-step instructions, which can degrade their native reasoning — give goals and constraints instead.
Tuning temperature AND top_p together blindly, producing unpredictable behavior; adjust one and keep the other near default.
Treating temperature=0 as fully reproducible — it is not guaranteed deterministic across infrastructure.
Passing temperature/top_p to reasoning models that reject them, causing 400 errors — check whether the model exposes sampling params.
Trusting retrieved or user-supplied text as instructions, opening prompt-injection holes; isolate untrusted data with delimiters and least-privilege tools.
Negative-only instructions ('don't do X') without a positive target — models follow concrete targets better.
Few-shot examples that are biased, imbalanced, or poorly ordered, which the model imitates literally.
Optimizing prompts by vibes with no eval set, so 'improvements' are unmeasured and regressions go unnoticed.
Forgetting max_tokens, causing silently truncated/invalid JSON outputs.
Interpolating timestamps, UUIDs, or user IDs into a cached prefix, silently invalidating the prompt cache on every request.
Assuming role-play ('act as an expert') adds knowledge — it only shapes style, not facts.

Interview tips

Compare zero-shot, few-shot, CoT, self-consistency, and ReAct — and say when each is and isn't worth the cost/latency.
Explain temperature vs top_p vs top_k precisely, including the softmax-with-temperature formula and which settings you'd pick for extraction vs creative tasks.
Discuss when to use prompt engineering vs RAG vs fine-tuning, with the trade-offs (cost, latency, maintainability, data needs).
Show how you'd evaluate a prompt: golden set, metrics, LLM-as-judge and its biases, and treating prompts as versioned, tested artifacts.
Describe prompt injection and concrete defenses (delimiters, instruction/data separation, least-privilege tools, output validation).
Know structured output and tool/function calling mechanics — schemas, strict validation, repair loops — and why they beat free-text JSON.
Mention prompt caching (prefix-match invariant) and token-cost math to show production/cost awareness.
Reference 2026 reality: native reasoning/extended-thinking models change CoT advice and may drop sampling params; automated optimizers (DSPy, meta-prompting) reduce hand-tuning.
Be ready to live-debug a failing prompt: identify the failure mode (format, hallucination, refusal, truncation, injection) and propose a targeted fix.

Read the full lesson Test yourself — 34 question quiz