What is prompt engineering, and what makes a good prompt?
Prompt engineering is writing and testing the input to an LLM so it reliably produces the output you need. Good prompts give clear instructions and context, show a few examples when the format matters, and ask for a specific output structure.
Explain it simply
Imagine you ask a new intern, "Make a report on placements." You will get something, but probably not what you wanted. Now imagine you say: "Make a one-page summary of this year's placement data for the principal. Include the number of students placed per branch and the highest package. Use a table. Here is last year's summary as an example." The second request gets a far better result from the same intern.
An LLM is that intern. It has broad knowledge but no idea of your goal, your audience or your format unless you tell it. Prompt engineering is the practice of giving it that information clearly, then checking the results and improving the prompt.
Example
A weak prompt and a stronger one for classifying support emails:
Weak:
Classify this email: "My debit card got blocked after 3 wrong PIN attempts."
Stronger:
You classify customer emails for a bank's support team.
Choose exactly one category: CARD, LOAN, ACCOUNT, OTHER.
Reply with JSON only: {"category": "...", "reason": "..."}
Example:
Email: "When will my home loan EMI be deducted?"
Answer: {"category": "LOAN", "reason": "Asks about EMI deduction date"}
Email: "My debit card got blocked after 3 wrong PIN attempts."
Answer:The stronger prompt sets a role, limits the choices, fixes the output format and shows one example. The result is easier to parse in code and more consistent across runs.
How it works
The main techniques:
- Clear instructions. State the task, the audience and the constraints directly. Say what to do, not only what to avoid.
- Context. Provide the data the model needs, such as the document to summarise. Separate it from instructions with clear markers or headings.
- Few-shot examples. Show one to a few input-output pairs. The model copies the pattern, which helps most for format and tone. Zero-shot means no examples.
- Structured output. Ask for JSON, a table or a fixed set of labels. Many APIs also offer a structured-output or JSON mode that enforces a schema.
- Breaking down the task. For multi-step problems, ask the model to work through steps, or split the job into several smaller prompts.
- System prompt. In chat APIs, a system message sets standing rules and the role for the whole conversation.
Treat prompts like code: keep a small set of test inputs, change one thing at a time, and compare the outputs.
Real-world use
- Turning free-text complaints into structured tickets.
- Generating product descriptions in a fixed brand tone.
- Summarising long reports into a fixed set of headings.
- Writing the instructions and context template used inside a RAG system.
Common mistakes
- Vague requests like "make it better", with no definition of better.
- Packing many unrelated tasks into one prompt.
- Giving examples that are all very similar, so the model copies their quirks.
- Not handling unexpected input, for example an email that fits no category. Always include an option like OTHER.
- Judging a prompt on one lucky output instead of testing it on many inputs.
What to say in the interview
"Prompt engineering is designing the input so the model reliably does the task. I give a clear role and task, the context it needs, and explicit constraints. If format matters I include a few examples, which is few-shot prompting, and I ask for structured output like JSON so my code can parse it. For complex tasks I break the work into steps. Then I test the prompt against a set of real inputs and refine it, because a prompt that works once may fail on edge cases."
Follow-up questions
- What is the difference between zero-shot and few-shot prompting?
- How do you make sure the model returns valid JSON every time?
- What is prompt injection, and how would you defend against it?
#prompt-engineering#few-shot#structured-output#llm#generative-ai