Core to Deep Dive
Prepare for questions on prompt design, few-shot and chain-of-thought patterns, structured output, evaluation, and injection defense.
Depth
Showing 5 of 5 questions
Short answer
Prompt engineering is the practice of designing and refining inputs to a language model to produce reliable, structured, and high-quality outputs. It is critical because a prompt determines whether the model follows instructions, formats output correctly, stays grounded in context, and resists adversarial content.
Interview-ready answer
I treat prompts as a runtime configuration layer, not a substitute for application logic. The system prompt defines immutable rules and safety constraints, while user-facing prompts handle the specific task. I iterate on prompts through structured evaluation rather than intuition: define success criteria, collect representative inputs, measure against a rubric, and version-control the prompt alongside code. A good prompt is concise, unambiguous, and testable — and it degrades predictably when inputs drift.
Common mistakes
Short answer
Zero-shot prompting asks the model to perform a task without examples. One-shot provides a single example, and few-shot provides multiple examples in the prompt to demonstrate the pattern, format, and reasoning style expected.
Interview-ready answer
I choose the shot count based on task ambiguity and output structure. Zero-shot works well for common tasks with unambiguous outputs. Few-shot helps with niche formats or complex reasoning — but each example consumes context tokens and can bias the model toward patterns in those examples. I place examples after the instruction and before the real input, ensure they cover typical and edge-case variations, and keep the total under 5–10 examples unless retrieval-augmented selection is used.
Common mistakes
Short answer
Chain-of-thought prompting asks the model to show intermediate reasoning before giving the final answer. It improves accuracy on arithmetic, logic, and multi-step tasks by exposing the model's reasoning to later steps and making partial credit and error localization possible.
Interview-ready answer
I use CoT for tasks that benefit from explicit reasoning steps such as math, multi-hop retrieval, and complex classification. For simple or well-structured tasks, CoT adds latency and token cost without measurable gain. Variants like self-consistency run multiple CoT chains and vote on the final answer, which improves reliability at higher cost. I evaluate whether CoT actually helps the specific task rather than applying it by default.
Common mistakes
Short answer
Provide an explicit schema or format specification in the prompt, include one or two valid examples, use constrained decoding or JSON-mode features where available, and validate outputs against the schema after generation with clear error handling.
Interview-ready answer
I specify the required structure upfront using the target format itself — JSON schema, XML DTD, or markdown template — rather than describing it in prose. I include a compact example, use the model's structured-output mode when available, and always validate the parsed result against a schema. For production systems, a retry-with-feedback loop lets the model fix minor formatting errors without manual intervention. I also test with malformed inputs to confirm the format constraint holds under adversarial conditions.
Common mistakes
Short answer
Define task-specific metrics, build a representative evaluation set, score outputs against a rubric, version prompts with code, and use A/B comparisons before deployment. Treat prompt evaluation as a continuous process, not a one-time review.
Interview-ready answer
I build a labeled evaluation set that covers typical inputs, edge cases, adversarial inputs, and known failure modes. Each test case has a rubric or expected output. For each prompt version, I run the eval set, compute pass rates by slice, and compare against the baseline. Automated scoring can use exact match, schema validation, or a model judge calibrated against human labels. Prompts are versioned alongside application code, and a regression in any slice blocks deployment. This turns prompt engineering from craft into measurable engineering.
Common mistakes