Prompt Engineering Fundamentals

Prompt engineering is now a skill asked of developers, analysts and product people alike. Interviewers are not looking for magic phrases; they want to see that you can turn a vague task into clear instructions, give the model the context it needs, and get output a program can rely on. Think of a prompt as a brief you would give a smart new colleague on day one.

1. What is prompt engineering, and why does it still matter with smarter models?

It is the practice of designing the instructions, context and examples you give a language model so it produces useful, reliable output. Newer models follow instructions much better, so tricks matter less — but clarity matters more than ever. The model cannot read your mind about the audience, format, constraints or edge cases; a good prompt supplies them. In production, prompts are code: versioned, tested and reviewed.

2. What are the parts of a good prompt?

• Role and context — who the output is for and why: “You are writing replies for a bank's support team; customers are often stressed.”
• Task — one clear goal.
• Input data — clearly separated, for example in XML-style tags.
• Constraints — length, tone, what to avoid, what to do when unsure.
• Output format — exact structure, ideally with an example.
• Examples — when the style is hard to describe.

You are helping a placement cell write feedback for students after mock interviews.
The students are final-year engineering students; keep the tone encouraging but honest.

<interview_notes>
{{notes}}
</interview_notes>

Write feedback with exactly three sections:
1. Strengths (2 bullet points)
2. What to improve (2 bullet points, each with one concrete practice step)
3. Overall readiness: one of "Ready", "Almost ready", "Needs practice"

If the notes do not mention communication skills, do not guess about them.

3. What is the difference between a system prompt and a user prompt?

The system prompt sets stable behaviour for the whole conversation: role, rules, tone, tools and format — written by the developer. The user prompt carries each request. Put durable instructions in the system prompt and keep user-provided content clearly separated, so the model treats it as data rather than as new rules.

4. Zero-shot vs few-shot prompting?

Zero-shot gives only instructions. Few-shot adds a few input→output examples, which is the fastest way to teach a specific format, tone or labelling scheme. Use varied examples that cover edge cases, mark them clearly as examples, and make sure they agree with your written rules — models copy examples closely, including their mistakes.

Classify each support message as BILLING, TECHNICAL or OTHER.

<examples>
Message: "I was charged twice for my subscription" → BILLING
Message: "The app crashes when I upload a PDF" → TECHNICAL
Message: "Do you have student discounts?" → BILLING
Message: "Can I change my username?" → OTHER
</examples>

Message: "{{message}}" →

5. How do you get reliable structured output such as JSON?

Best: use the API's structured-output feature (a JSON schema the response must follow) or tool/function calling with a strict schema — the platform then guarantees valid JSON. Without that, describe the schema precisely, show an example, ask for JSON only, and always validate the result in code with a retry on failure.

{
  "type": "object",
  "properties": {
    "sentiment": { "type": "string", "enum": ["positive", "neutral", "negative"] },
    "topics":    { "type": "array", "items": { "type": "string" } },
    "needs_reply": { "type": "boolean" }
  },
  "required": ["sentiment", "topics", "needs_reply"],
  "additionalProperties": false
}

6. Why use delimiters such as XML tags in prompts?

They separate instructions from data and label each part: <document>, <customer_email>, <rules>. This reduces confusion when inputs are long, lets you refer to parts by name (“using the policy in <policy>…”) and makes it harder for text inside the data to be mistaken for instructions.

7. How do you reduce hallucinations?

Ground the model in source material (paste the document or retrieve it with RAG) and tell it to answer only from that source. Explicitly allow “I don't know” or “not in the document”. Ask for quotes or citations for each claim. Lower the ambition of the task (extraction instead of open-ended generation) where accuracy matters, and verify important facts in code or with a second check.

Answer the question using only the policy below.
If the policy does not answer it, reply exactly: "The policy does not cover this."
After your answer, quote the sentence from the policy that supports it.

<policy>
{{refund_policy}}
</policy>

Question: {{question}}

8. How do you improve a prompt that gives inconsistent results?

Treat it like debugging. Collect failing examples, read the outputs to understand why they fail, and change one thing at a time: clarify the instruction, add missing context, add an example of the tricky case, or tighten the format. Keep a small test set and re-run it after every change so a fix for one case does not break three others.