Tips for better prompts
-
Introduction to generative AI and agents
-
Large language models (LLMs)
-
Prompts
-
AI agents
You’ve written a lot of prompts in this section. Some worked the first time.
Most needed a few tries, and a few worked on Monday and failed on Friday for no clear reason. Prompt engineering is the skill of getting from “it worked once” to “it works every time”: clear instructions, the right facts, a good example, and a set of tests that tells you, in seconds, whether a change made things better or worse.
In this lesson you’ll turn rough engineer notes into status updates that any member of staff can read. You’ll write the tests first, then improve the prompt one habit at a time and watch the score climb from 0 to 6 out of 6. Then you’ll break it twice: once with a friendly-sounding wording change, and once by switching to a bigger model.
| Time | You need | By the end you can |
|---|---|---|
| About 60 minutes | Python 3 and Ollama with llama3.2:1b. For the second Break It lab, llama3.2:3b (2.0 GB, from Lesson 2) | Use a 7-point prompt checklist, write automatic checks for a prompt, measure every change, and catch a change that quietly breaks other cases |
What it is, in one line
Prompt engineering means writing clear instructions for a model, then testing them on real examples until they work every time, and testing again whenever anything changes.
In Simple Words
Sending a friend to the shop
You ask a friend to pick up “some fruit”. They come back with a pineapple and a bag of grapes.
They did exactly what you asked. You just didn’t ask for what you wanted.
Next time you write a list: “6 bananas, not too ripe. If there are no bananas, get apples. Spend less than 100 rupees.”
You say what you want, how much, what to avoid, and what to do if something goes wrong. You might even show them a photo of the right bananas.
And when they come back, you check the bag. If you change the list next week, you check the whole bag again, not just the item you changed, because “get the cheapest” might have turned your good rice into bad rice.
A prompt is that shopping list. The model is a fast, willing friend who never asks questions. Prompt engineering is writing a good list, and always checking the bag.
Engineer's View
Seven habits, and a test set
Each habit below is something you met earlier in this section. Together they make a checklist you can run through for any prompt.
- Define “good” first, as tests. Collect real inputs and write down what a good output must do. If you can’t say how you’d check it, the prompt isn’t ready to write.
- Say the task, the reader and the limits. Who is it for, what should it contain, how long, in what tone (Lesson 8, the parts of a prompt).
- Give the facts, clearly marked. Put input data in its own message or between tags, so the model can tell instructions from data (Lesson 8) and so it answers from your facts, not its memory (Lesson 11).
- Say what to do, not only what to avoid. “Use plain words” works better than a list of banned words. When you do ban something, say what to do instead.
- Show a good example. One or two worked examples often fix what rules can’t (Lesson 9). Keep them different from your test cases.
- Fix the shape of the output. A word limit and plain text for people; a JSON schema through Ollama’s
formatoption for code (Lesson 8). - Make it repeatable. Use temperature 0 for fixed jobs (Lesson 7), keep the history short (Lesson 10), pin the model version, and rerun every test after every change.
Testing prompts. The test set (often called an eval set) is the most important part. Start with 6 to 20 real inputs, and add every case that ever fails in production. There are a few ways to check outputs:
- Exact match for labels and numbers, as in Lesson 9.
- Rule checks in code: word count, required words, regular expressions for things that must never appear. Cheap, fast and repeatable. You’ll use these in the lab.
- Schema validation for JSON: the right keys and allowed values.
- LLM-as-judge: a second model scores qualities rules can’t catch, such as tone or whether the answer is faithful to the source. Useful, but the judge needs its own tests and can be biased.
- Human review of a sample, to keep everything else honest.
Prompts are code. Keep them in version control, review changes, and run the test set in CI before any prompt or model change goes live. A tag such as llama3.2:1b can point to a new build after you pull it again, and hosted APIs retire and replace model versions, so record exactly which model each test run used.
Why it matters on the job: most LLM bugs are prompt bugs that nobody tested. A team with a 20-case test set can change a prompt in five minutes with confidence; a team without one argues about screenshots.
How it works, step by step
Here’s the checklist on one page. Run through it top to bottom for any new prompt:
The checklist gets you a good first version. The test loop keeps it good:
- Collect real cases. Six old incident notes, each with the facts a good update must keep: the service name and the next update time.
- Write one check per rule. At most 60 words, names the service, gives the next update time, and shows no IP address or server name.
- Run every case and read the failures. The score tells you how bad it is; the failing outputs tell you why.
- Change one thing. One rule, one example, or one setting. If you change three things at once, you won’t know which one helped.
- Run every case again. Keep the change only if the score went up and nothing that passed before fails now.
This is the path you’ll follow in the lab, including the two changes that made things worse:
Look at the first red bar. A teammate asked for a warmer tone, and four of the six tests broke. Without a test set, that change would have gone live, and the first sign of trouble would have been a server name on the staff portal.
Do I need a test set for a one-off prompt?
No. If you’re asking a model to rewrite one email, just read the answer. Tests pay off when a prompt runs again and again: inside an app, a script, a bot or a scheduled job. That’s where nobody reads every output, and where one bad change reaches hundreds of people.
Hands-on Lab: prompt engineering with a test set
One script does everything. update_test.py holds six real-style incident notes, builds the prompt, sends each note to the model, and checks every update against four rules. The checks run in your Python, so the PASS and FAIL lines are always correct for the text the model wrote.
The model’s words will differ a little on your laptop, so your score may be off by one; the prompt token counts below are exact. On macOS or Linux, use python3 and nano.
1Write the tests, then the shortest prompt
Run this:
mkdir C:\ai-lab\prompt-tips
cd C:\ai-lab\prompt-tips
notepad update_test.pyPaste this whole block into update_test.py, then save:
import json
import re
import urllib.request
MODEL = "llama3.2:1b"
PROMPT = "short" # "short", "clear" or "example"
EXTRA = "" # one more instruction, added after the rules
TEMPERATURE = 0
RUNS = 1 # how many times to run each test
RULES = """You write status updates about IT incidents for all staff.
The readers are not technical, so use plain words.
Write at most 60 words, as plain text with no headings.
Say which service is affected, what staff should do now, and the time of the next update.
Leave out IP addresses, server names and people's names."""
EXAMPLE = """Here is an example.
Notes: 13:05 vpn-gw-01 CPU 100%, users dropping. Restarted service, still failing. Vendor case 88213 opened. Workaround: work from office. Next update 13:45.
Update: The VPN is dropping connections for staff working from home. We are working on it with our supplier. If you can, please work from the office until it is fixed. Next update at 13:45."""
TESTS = [
{"service": "email", "next": "09:40",
"notes": "09:10 srv-mail-02 not accepting connections, Outlook stuck on 'Trying to connect'. Log disk on 10.20.4.15 full, clearing old logs. Ravi on it. Next update 09:40."},
{"service": "wi-fi", "next": "11:50",
"notes": "11:20 Staff and guest Wi-Fi down on floors 2 to 4. Controller wlc-core-01 rebooted itself, access points rejoining slowly. Wired network fine. Next update 11:50."},
{"service": "print", "next": "14:30",
"notes": "14:00 Print queue on prn-srv-03 stuck, all jobs pending across the building. Spooler restart failed. Priya checking the driver update from last night. Next update 14:30."},
{"service": "payroll", "next": "16:45",
"notes": "16:15 Payroll app gives error 500 for everyone. sql-prod-03 (10.20.8.7) failed over, app pool not reconnecting. Payday is tomorrow. Next update 16:45."},
{"service": "teams", "next": "10:35",
"notes": "10:05 Teams calls drop after 2 or 3 minutes for all users. Chat works. fw-edge-02 firmware updated last night, suspect a UDP rule. Next update 10:35."},
{"service": "laptop", "next": "09:00",
"notes": "08:30 Staff can't sign in to laptops: 'The trust relationship failed'. dc-hyd-01 clock 9 minutes out. Workaround: unplug the network cable and sign in, then plug it back. Next update 09:00."},
]
def ask(messages):
body = {"model": MODEL, "messages": messages, "stream": False,
"options": {"temperature": TEMPERATURE}}
req = urllib.request.Request("http://localhost:11434/api/chat", data=json.dumps(body).encode(),
headers={"Content-Type": "application/json"})
with urllib.request.urlopen(req) as r:
return json.load(r)
def build(notes):
if PROMPT == "short":
return [{"role": "user", "content": "Write a status update from these notes:\n" + notes}]
system = RULES + ("\n" + EXTRA if EXTRA else "")
if PROMPT == "example":
system += "\n\n" + EXAMPLE
return [{"role": "system", "content": system},
{"role": "user", "content": "Notes: " + notes}]
def check(update, test):
problems = []
words = len(update.split())
if words > 60:
problems.append(f"too long ({words} words)")
if test["service"] not in update.lower():
problems.append(f"doesn't name the service ({test['service']})")
if test["next"] not in update:
problems.append(f"no next update time ({test['next']})")
if re.search(r"\b\d{1,3}(\.\d{1,3}){3}\b|\b[a-z]+-[a-z0-9]+-\d+\b", update.lower()):
problems.append("shows an IP address or server name")
return problems, words
print(f"Prompt: {PROMPT} | model: {MODEL} | temperature: {TEMPERATURE} | {len(TESTS)} tests x {RUNS} run(s)")
passed = total = tokens = 0
for n, test in enumerate(TESTS, 1):
for run in range(RUNS):
r = ask(build(test["notes"]))
update = r["message"]["content"].strip()
problems, words = check(update, test)
total += 1
tokens += r["prompt_eval_count"]
if problems:
print(f"FAIL {n} {test['service']:<8} " + "; ".join(problems))
shown = " ".join(update.split())
print(f" {shown[:88]}{'...' if len(shown) > 88 else ''}")
else:
passed += 1
print(f"PASS {n} {test['service']:<8} ({words} words)")
print(f"Passed {passed} of {total} | prompt tokens per test: {tokens / total:.0f} on average")Read TESTS and check first. That’s habit 1: before writing any prompt, you’ve written down what a good update must do.
The settings at the top choose the prompt. Start with the shortest one: “Write a status update from these notes”.
Run this:
python update_test.pyYou should see something like this (prompt tokens exactly 79):
Prompt: short | model: llama3.2:1b | temperature: 0 | 6 tests x 1 run(s)
FAIL 1 email too long (66 words); shows an IP address or server name
**Status Update: Email Service Disruption** At 09:10, our mail server srv-mail-02 stoppe...
FAIL 2 wi-fi shows an IP address or server name
**Network Status Update** At 11:20, staff and guest Wi-Fi went down on floors 2 to 4. Th...
FAIL 3 print too long (63 words); shows an IP address or server name
**IT Incident Update - Printing** We are currently experiencing an issue with the print ...
FAIL 4 payroll shows an IP address or server name
**Urgent: Payroll Application Outage** The payroll application is currently returning er...
FAIL 5 teams shows an IP address or server name
**Microsoft Teams Call Issues** Since 10:05, Teams calls are dropping after 2 to 3 minut...
FAIL 6 laptop shows an IP address or server name
**Laptop Sign-In Issue** Staff are currently unable to sign in to their laptops and are ...
Passed 0 of 6 | prompt tokens per test: 79 on averageNothing passes. Read the updates: markdown headings, “srv-mail-02”, an internal IP address, “UDP rule”. These are engineer’s notes in nicer sentences.
The model isn’t wrong; nobody told it who reads the update or what to leave out. 79 tokens is 25 hidden template tokens plus a one-line prompt and the notes.
✅ Checkpoint: Passed 0 of 6, and every update fails the IP address or server name check.
2Say who it’s for and what good looks like
Switch to the prompt with the RULES text: the readers, the length, what to include and what to leave out. The notes now go in their own user message, after the label Notes:.
Change this line:
PROMPT = "clear"Run this:
python update_test.py
You should see something like this (prompt tokens exactly 142 on average):
Prompt: clear | model: llama3.2:1b | temperature: 0 | 6 tests x 1 run(s)
PASS 1 email (32 words)
FAIL 2 wi-fi shows an IP address or server name
Wi-Fi is down on floors 2 to 4 because the controller wlc-core-01 restarted. The wired n...
PASS 3 print (32 words)
FAIL 4 payroll no next update time (16:45)
The payroll app is showing an error for everyone. We know payday is tomorrow and our tea...
PASS 5 teams (34 words)
PASS 6 laptop (33 words)
Passed 4 of 6 | prompt tokens per test: 142 on averageFour out of six, and the updates now read like something staff can use. Two still fail. Test 2 explains the cause and names the controller, wlc-core-01, even though the rules say no server names.
Test 4 forgot the next update time and said “soon”. A small model follows most rules most of the time; your checks find the ones it missed.
✅ Checkpoint: Passed 4 of 6. The failures are a server name in test 2 and a missing time in test 4.
3Show one good example
The EXAMPLE text shows one set of notes and one good update. It’s about the VPN, which isn’t in any test, so the model has to learn the style instead of copying an answer.
Change this line:
PROMPT = "example"Run this:
python update_test.pyYou should see something like this (prompt tokens exactly 237 on average):
Prompt: example | model: llama3.2:1b | temperature: 0 | 6 tests x 1 run(s)
PASS 1 email (32 words)
PASS 2 wi-fi (33 words)
PASS 3 print (32 words)
PASS 4 payroll (31 words)
PASS 5 teams (34 words)
PASS 6 laptop (33 words)
Passed 6 of 6 | prompt tokens per test: 237 on averageSix out of six. The example showed what the rules only described: “vpn-gw-01 CPU 100%” becomes “the VPN is dropping connections”, and the update ends with “Next update at 13:45”.
The price is 95 more tokens on every call. For a status update that’s fine; for a million calls a day, you’d measure whether a shorter example works as well.
✅ Checkpoint: Passed 6 of 6 with the example prompt.
4Make sure it passes every time
One good run proves less than you think. Run every test three times at Ollama’s default temperature:
Change these two lines:
TEMPERATURE = 0.8
RUNS = 3Run this:
python update_test.pyYou should see something like this (the model’s words will differ a little):
Prompt: example | model: llama3.2:1b | temperature: 0.8 | 6 tests x 3 run(s)
PASS 1 email (32 words)
PASS 1 email (31 words)
PASS 1 email (30 words)
PASS 2 wi-fi (33 words)
PASS 2 wi-fi (34 words)
FAIL 2 wi-fi shows an IP address or server name
Wi-Fi is down on floors 2 to 4 after the controller wlc-core-01 restarted itself. Please...
PASS 3 print (32 words)
PASS 3 print (32 words)
PASS 3 print (25 words)
PASS 4 payroll (31 words)
FAIL 4 payroll no next update time (16:45)
The payroll app is showing an error for everyone. We are working on it urgently because ...
PASS 4 payroll (29 words)
PASS 5 teams (34 words)
PASS 5 teams (24 words)
PASS 5 teams (29 words)
PASS 6 laptop (33 words)
PASS 6 laptop (31 words)
PASS 6 laptop (29 words)
Passed 16 of 18 | prompt tokens per test: 237 on averageSame prompt, same notes, and two of 18 runs fail. At temperature 0.8 the model picks different words each time (Lesson 7), and sometimes those words break a rule.
If you’d tested once and seen 6 out of 6, you’d have shipped a prompt that fails about one time in nine. Status updates should be predictable, so turn the randomness off:
Change this line:
TEMPERATURE = 0Run this:
python update_test.pyYou should see something like this (the model’s words will differ a little):
Prompt: example | model: llama3.2:1b | temperature: 0 | 6 tests x 3 run(s)
PASS 1 email (32 words)
PASS 1 email (32 words)
PASS 1 email (32 words)
PASS 2 wi-fi (33 words)
PASS 2 wi-fi (33 words)
PASS 2 wi-fi (33 words)
PASS 3 print (32 words)
PASS 3 print (32 words)
PASS 3 print (32 words)
PASS 4 payroll (31 words)
PASS 4 payroll (31 words)
PASS 4 payroll (31 words)
PASS 5 teams (34 words)
PASS 5 teams (34 words)
PASS 5 teams (34 words)
PASS 6 laptop (33 words)
PASS 6 laptop (33 words)
PASS 6 laptop (33 words)
Passed 18 of 18 | prompt tokens per test: 237 on averageAt temperature 0 the model always takes the most likely token, so all three runs give the same update, and 18 out of 18 pass. For creative jobs you might keep some randomness, and then you’d test several runs every time.
✅ Checkpoint: Passed 16 of 18 at temperature 0.8, and 18 of 18 at temperature 0.
Break It, Then Fix It
Both of these changes look harmless. Neither shows an error. Only the tests notice.
1Break it: a friendly change that breaks four tests
The service manager reads a few updates and says they feel cold. A teammate adds one line to make them warmer, checks one update by eye, and it looks lovely:
Change these two lines:
EXTRA = "Be warm and friendly, say sorry, and explain what went wrong."
RUNS = 1Run this:
python update_test.pyYou’ll see something like this:
Prompt: example | model: llama3.2:1b | temperature: 0 | 6 tests x 1 run(s)
FAIL 1 email shows an IP address or server name
We're so sorry! We know how frustrating it is when email stops working. Here's what happ...
PASS 2 wi-fi (37 words)
FAIL 3 print too long (78 words)
We're really sorry about this! Printing isn't working anywhere in the building. Here's w...
FAIL 4 payroll shows an IP address or server name
We're very sorry, and we know payday is tomorrow, so this is our top priority. The payro...
FAIL 5 teams shows an IP address or server name
Sorry about the dropped calls! Teams calls are cutting off after two or three minutes. W...
PASS 6 laptop (40 words)
Passed 2 of 6 | prompt tokens per test: 251 on averageFrom 6 out of 6 to 2. “Explain what went wrong” asked for the technical cause, and the cause is where the server names live: srv-mail-02, sql-prod-03, fw-edge-02. The printing update grew to 78 words.
The new instruction fought the old rules, and the model followed the newest one. Now read the full update for test 1:
Test 1, in full:
We're so sorry! We know how frustrating it is when email stops working. Here's
what happened: the log disk on our mail server srv-mail-02 filled up, so it
stopped accepting connections and Outlook got stuck on 'Trying to connect'. Ravi
is clearing old logs right now. Please use Teams chat for anything urgent. Next
update at 09:40.It also names Ravi, and none of your checks noticed, because there’s no check for people’s names. A rule without a check is a rule you’re hoping for. In a real system you’d add one, for example a list of staff names from your directory.
The fix: keep the warm tone, drop the part that fights the rules:
Change this line:
EXTRA = "Start with one short, friendly sorry."Run this:
python update_test.pyYou should see something like this (the model’s words will differ a little):
Prompt: example | model: llama3.2:1b | temperature: 0 | 6 tests x 1 run(s)
PASS 1 email (36 words)
PASS 2 wi-fi (37 words)
PASS 3 print (36 words)
PASS 4 payroll (35 words)
PASS 5 teams (38 words)
PASS 6 laptop (37 words)
Passed 6 of 6 | prompt tokens per test: 245 on averageEvery update now starts with “Sorry for the trouble.” and all six pass. The manager gets the warmer tone, and the rules still hold. The real lesson is the process: change one thing, then run every test, not just the one you were looking at.
✅ Checkpoint: The warm, explaining version passes 2 of 6. The one-sorry version passes 6 of 6.
2Break it again: a bigger model, a worse score
The team decides the 3B model is “better” and switches to it without running the tests. If you don’t have it from Lesson 2, download it first:
Run this:
ollama pull llama3.2:3bChange this line:
MODEL = "llama3.2:3b"Run this:
python update_test.py
You’ll see something like this:
Prompt: example | model: llama3.2:3b | temperature: 0 | 6 tests x 1 run(s)
PASS 1 email (36 words)
PASS 2 wi-fi (37 words)
FAIL 3 print too long (71 words)
**Printing update** Sorry for the trouble. Printing is not working anywhere in the build...
PASS 4 payroll (35 words)
PASS 5 teams (38 words)
FAIL 6 laptop too long (71 words)
**Laptop sign-in update** Sorry for the trouble. Some staff can't sign in to their lapto...
Passed 4 of 6 | prompt tokens per test: 245 on averageA bigger model, and two tests fail. The 3B model writes longer, more thorough updates and adds a bold heading, even though the rules say no headings.
It’s not worse at language; it reads the same prompt differently. Prompts are tuned to a model, and every model change is a prompt change.
The fix: make the length rule something the model can count more easily:
Change this line:
EXTRA = "Start with one short, friendly sorry. Use no more than 4 short sentences."Run this:
python update_test.pyYou should see something like this (the model’s words will differ a little):
Prompt: example | model: llama3.2:3b | temperature: 0 | 6 tests x 1 run(s)
PASS 1 email (36 words)
PASS 2 wi-fi (37 words)
PASS 3 print (30 words)
PASS 4 payroll (35 words)
PASS 5 teams (38 words)
PASS 6 laptop (31 words)
Passed 6 of 6 | prompt tokens per test: 254 on averageSix out of six on the 3B model. Now check the new rule didn’t break the small model:
Change this line:
MODEL = "llama3.2:1b"Run this:
python update_test.pyYou should see something like this (the model’s words will differ a little):
Prompt: example | model: llama3.2:1b | temperature: 0 | 6 tests x 1 run(s)
PASS 1 email (36 words)
PASS 2 wi-fi (37 words)
PASS 3 print (36 words)
PASS 4 payroll (35 words)
PASS 5 teams (38 words)
PASS 6 laptop (37 words)
Passed 6 of 6 | prompt tokens per test: 254 on averageOne prompt, two models, all tests passing. Notice that the extra sentence costs 9 tokens on every call (245 to 254). When you move to a new model, run the tests on both, fix the prompt, and keep the test results with the change.
✅ Checkpoint: With the 4-sentence rule, both llama3.2:3b and llama3.2:1b pass 6 of 6.
This happened at work
The status page that said too much
A company used a hosted LLM to draft its public status-page updates from the on-call engineer’s notes. The engineer read each draft and clicked Approve.
The prompt said “be clear and thorough”, and it called the model through an alias that always pointed to the provider’s latest version. It had worked well for months.
On a Thursday evening the provider moved the alias to a newer model. Nobody on the team knew. On Saturday night, during a database outage, the new model took “thorough” seriously: its drafts included the database host name, an internal IP range and the supplier’s ticket number.
The on-call engineer was busy fixing the database, glanced at the first line, and approved. For about 40 minutes, the public status page showed a map of part of the internal network.
The fix: the model version is now pinned and changed only on purpose. Twenty-five old incident notes became a test set that runs automatically on every prompt or model change, with the same kind of checks as your lab.
The IP address and host name check also runs on every live draft and blocks the Approve button if it matches. And “be thorough” was replaced by rules about what the reader needs.
The lesson: your tests protect you twice. Before a change, they show what it breaks. In production, the same checks catch the bad output that slips through anyway.
Common mistakes and troubleshooting
| Mistake | What happens | How to avoid it |
|---|---|---|
| Changing the prompt and checking one example by eye | Other cases break quietly | Run the whole test set after every change |
| Testing once at a high temperature | A prompt that fails some of the time looks perfect | Use temperature 0 for fixed jobs, or run each test several times |
| Rules with no checks | The model breaks them and nobody notices | Write one check per rule; review a sample by hand for the rest |
| Using test cases as the examples in the prompt | A perfect score that means nothing | Keep examples and tests separate, like training and test data |
| Changing the model or pulling a new version without testing | Longer, different or broken output | Pin the model version and rerun the tests on every model change |
| Only saying what not to do | The model doesn’t know what to do instead | Say what you want; add a reason or an alternative for each ban |
| Adding a rule for every complaint | Long, slow prompts with rules that fight each other | Remove rules no test needs; turn each complaint into a test case first |
Troubleshooting the lab
| Problem | Fix |
|---|---|
urllib.error.HTTPError: HTTP Error 404: Not Found | The model isn’t downloaded. Run ollama pull llama3.2:1b (or llama3.2:3b) |
urllib.error.URLError: <urlopen error [WinError 10061] | Ollama isn’t running. Start the Ollama app, or run ollama serve |
| The score doesn’t change when you edit PROMPT | Check the spelling: "short" and "example" must be lowercase. Any other value uses the clear prompt |
| Your score is one higher or lower than the lesson | Expected. Read the FAIL lines: the reasons should be the same kinds of problems |
| The 3B model is very slow | It’s bigger than the 1B model (a 2.0 GB download against 1.3 GB) and needs more memory. Close other apps, or skip that step and read the results |
| Every test fails with “too long” | Check that your EXTRA line didn’t add a request to explain or give details |
Interview questions
Click a question to open it. Under each one you’ll find what the interviewer is actually looking for, and one good way to answer.
Fresher level
1. What is prompt engineering?
What they’re really checking: Do you see it as more than clever wording?
How you could answer: Writing clear instructions for a model, with the task, the reader, the facts, the output format and examples, and then testing the prompt on real inputs until it works reliably. The testing part matters as much as the writing.
2. Name a few things that make a prompt better.
What they’re really checking: Do you know the basic habits?
How you could answer: Say exactly what you want and who it’s for, give the needed facts clearly separated from the instructions, set the length and format, say what to do instead of only what to avoid, and show a good example.
3. Why would you set the temperature to 0?
What they’re really checking: Do you connect sampling to reliability?
How you could answer: Temperature 0 makes the model pick the most likely token every time, so the same prompt gives the same output. That’s what you want for fixed jobs like classification, extraction or status updates, and it makes test results repeatable.
2–5 years experience
4. How do you test a prompt?
What they’re really checking: Have you built an eval set before?
How you could answer: Collect real inputs, including past failures, and define what a good output must do. Write automatic checks: exact match for labels, rule checks for length and forbidden content, schema validation for JSON. Run the whole set after every change, track the score per version, and review a sample by hand.
5. A prompt change fixed one complaint, but new problems appeared. What went wrong?
What they’re really checking: Do you understand prompt regressions?
How you could answer: The change was checked on one example only. Instructions interact: a new line can override or fight older rules. The process fix is to add the complaint as a test case, change one thing, and run the full test set before releasing, keeping the change only if nothing that passed now fails.
6. Rule-based checks or LLM-as-judge?
What they’re really checking: Do you know the trade-offs?
How you could answer: Rule checks are cheap, fast and exact, so I use them wherever a rule can be written in code. An LLM judge helps with qualities like tone, helpfulness or faithfulness, but it costs more, can be biased and needs its own tests against human labels. Most teams use both, plus a human review of samples.
Senior level
7. How would you manage prompts in production?
What they’re really checking: Can you treat prompts as software?
How you could answer: Store prompts in version control with the model version they were tested on. Review prompt changes like code.
Run the eval set in CI on every prompt or model change and block releases that lower the score. Pin model versions, run cheap checks on live outputs too, and log inputs and outputs so new failures become new test cases.
8. You have to move to a new model version. How do you plan it?
What they’re really checking: Do you know models aren’t drop-in replacements?
How you could answer: Run the current eval set on both models and compare scores, cost and latency per case. Read the cases that changed.
Adjust the prompt for the new model and check it still works on the old one if you need to roll back. Then release gradually, for example to a share of traffic, while watching the live checks.
9. How do you build a good eval set and avoid overfitting to it?
What they’re really checking: Do you understand evaluation hygiene?
How you could answer: Use real, varied inputs, including edge cases and past failures, and get expected results agreed with the people who own the outcome. Keep a held-out set you don’t look at while tuning, keep prompt examples separate from tests, and refresh the set as real usage changes.
Quick quiz
Q1. Why did the shortest prompt score 0 out of 6?
- The model was too small to write updates
- It never said who reads the update or what to leave out
- The notes were in the wrong order
Show answer
B — The model wrote reasonable engineer-style text, because nothing told it the readers aren’t technical.
Q2. Why does the example in the prompt use a VPN incident that isn’t in the tests?
- So the model learns the style instead of copying an answer
- Because VPN incidents are the most common
- To make the prompt shorter
Show answer
A — If the example were one of the tests, a perfect score would only prove the model can copy.
Q3. At temperature 0.8, 16 of 18 runs passed. What does that show?
- The checks are broken
- One passing run doesn’t prove a prompt is reliable
- Temperature has no effect
Show answer
B — Random sampling sometimes picks words that break a rule. Test several runs, or use temperature 0 for fixed jobs.
Q4. Adding “explain what went wrong” dropped the score to 2 of 6. What should the teammate have done?
- Run all the tests before keeping the change
- Use a bigger model
- Remove the checks
Show answer
A — The change was checked on one update by eye. The full test set would have caught it in seconds.
Q5. Switching to llama3.2:3b made two tests fail. What’s the lesson?
- Bigger models are always worse
- A model change is a prompt change, so rerun the tests
- Never use 3B models
Show answer
B — Different models read the same prompt differently. Test, adjust, and test both.
Quick recap
- Prompt engineering = clear instructions plus tests on real examples.
- Run the checklist: define good as tests, say the task and the reader, give the facts, say what to do, show an example, fix the shape, make it repeatable.
- Write one check per rule. A rule without a check is a hope.
- Change one thing, then run every test. Keep the change only if nothing breaks.
- Test several runs, or use temperature 0 for fixed jobs.
- Every model change is a prompt change: pin versions and rerun the tests.
Next lesson
AI agents → That’s the end of the prompts section. So far the model only writes text, and your code does everything else. In the next section the model starts to act: an AI agent decides which tool to use, reads the result, and decides what to do next.
Further reading: prompt engineering
Want to go deeper into prompt engineering? Read the prompt engineering overview from Anthropic and the community Prompt Engineering Guide. You can also follow the full Generative AI and Agents course on SaatVedha, step by step.
