Prompt Engineering

Interviewers do not ask about prompt engineering to see whether you can phrase a request politely. They ask because the prompt is the interface between a non-deterministic model and a production system that needs deterministic guarantees — a schema downstream code can parse, a behavior that does not regress when you change one sentence, a cost and latency budget that the prompt's own length controls. Treated as "typing nicely," prompt engineering is a five-minute topic. Treated as an engineering discipline, it has the same concerns as any other interface: versioning, testing, rollback, and a clear boundary between what is trusted and what is not.

The discipline shows up in three places an interviewer will probe. First, structure: separating instructions from data (system vs user, and later, retrieved or tool-returned content) is not a style preference, it is the only thing standing between your application and prompt injection. Second, technique: few-shot examples and chain-of-thought are not free — each buys a specific effect (format conformance, or more inference-time compute before an answer) at a specific cost (tokens, latency, sometimes worse performance), and a senior engineer can say which effect they're paying for. Third, process: prompts that ship to production are versioned, evaluated against a golden set before every change, and rolled back like any other code artifact when a regression appears in production traces.

This subject covers all three, plus the question interviewers use to separate candidates who have shipped LLM features from those who have only played with a playground: when do you stop iterating on the prompt and reach for RAG or fine-tuning instead? That decision framework is covered in full in llm-application-system-design; this subject gives the compressed, prompt-engineer's-eye version of it, because you cannot make that call well without first understanding what a prompt can and cannot be pushed to do.