Prompt engineering fundamentals

Why it matters

Prompting is the cheapest lever in any LLM system and the one most teams pull badly. The same model, given the same data, swings from unusable to shippable on the wording of a few hundred tokens, and most of that swing is structure, not clever phrasing. Interviewers ask about prompts early because the answer reveals whether a candidate treats the model as an oracle to be coaxed or as a component to be specified.

The idea

A prompt is a specification. It tells a general-purpose model what job it is doing, what it has been given, what a correct output looks like, and what to do when the input does not fit.

The parts

Role and task. One or two sentences naming what the model is and what it produces: "You classify support tickets for a payments company into one of six queues." Role framing narrows the range of likely outputs and sets the register.

Explicit instructions. Rules written the way you would write them for a contractor: positive, specific, testable. "Reply in under 80 words" beats "be concise"; "use only facts stated in the ticket" beats "be accurate".

Delimited input. Data the model must read goes inside clear markers: XML-style tags, triple backticks or a labelled block. Delimiting tells the model where instructions end and material begins, and it is the first defence against text inside the data that looks like an instruction.

Output format. State the shape: a JSON object with named keys, a numbered list, one word from a fixed set. Where code consumes the output, give a schema and ask for nothing outside it.

Examples. Two to five worked input-output pairs, called few-shotA prompt that includes a few worked examples of the task before the real input. prompting, show what instructions cannot say: tone, edge-case handling, how terse a field should be. They cost tokens on every call and bias the model towards their surface features, so use them for format and style, not for teaching facts.

Constraints and the unsure path. Say what to do when the input is ambiguous, off-topic or missing: return needs_review, ask one question, or refuse. A prompt without an unsure path forces the model to guess, and it guesses fluently.

Order

Instructions first and data last is the default: the model reads the rules, then the material, then answers. With long documents the reverse works better: data first, then the instructions and the question at the end, close to where the answer is generated. Attention to the ends of the window is stronger than to the middle, so put the thing that must be obeyed where it is least likely to be lost. Either way, stable parts come before per-call parts, which also makes the prompt cacheable.

System versus user

The system prompt carries the standing specification: role, rules, format, examples. The user turn carries this call's input and question. Providers train models to give the system prompt precedence, so rules placed there hold better against a user who tries to override them. Keep per-request data out of the system prompt; keep policy out of the user turn.

Iterate against an eval set, not vibes

Collect 50 to 200 real inputs with the outputs you want, run every prompt change against them and read the diff. A change that fixes the example you were staring at and breaks eight others is invisible without the set. The Evaluation module turns the habit into a pipeline.

	Zero-shot	Few-shot	Instructions + schema
Reliability	Varies with wording; fine for common tasks	Consistent format and tone; copies example quirks	Highest for parseable output; enums block invention
Token cost per call	Lowest	Plus 200 to 2,000 tokens of examples every call	Plus the schema, usually a few hundred tokens
Maintenance	Edit a sentence	Examples drift from reality and must be curated	Schema is versioned with the code that reads it
Best for	Chat, drafting, one-off tasks	Style, edge cases, formats hard to describe	Classification, extraction, anything consumed by code

Anti-patterns

Vague adjectives: "professional", "engaging", "detailed" name nothing testable. Contradictory rules: "answer fully" next to "keep it to one line" let the model pick. Hidden assumptions: a date, a currency or the reader's expertise that lives in the author's head and not in the prompt. Negative instructions that name the thing ("do not mention competitors") and so make it likelier. Rules stacked over months until nobody knows which still fire.

Trade-offs

More instructions buy reliability and cost tokens, latency and attention; past a point each new rule dilutes the others. Few-shot examples lift consistency and quietly cap it: the model copies their length and their mistakes. A strict schema can suppress hedging you wanted to see. Prompts tuned hard to one model drift when the model changes, which is why the eval set, not the prompt, is the durable asset.

In an interview

Say: "I write a prompt as a spec with six parts, I delimit the data, I give it a schema and an unsure path, and I judge changes on an eval set, not on one example." At junior depth, name the parts and why delimiting matters. At mid depth, explain ordering for long inputs, the cost and bias of few-shot, and system-versus-user precedence. At senior depth, tie prompts to versioning, caching and injection, and describe how a prompt change ships through evals. Expect: "How would you know a prompt change made things better?"