Describe your process for improving a prompt that is giving mixed results.
What the interviewer wants to hear
- Collect failing and passing examples
- Find patterns in failures
- Change one thing at a time
- Re-test on the full set and keep versions
Model answer
First I gather examples: a set of real inputs with notes on what a good output looks like, including the cases that are failing. I run the current prompt on all of them and sort failures into patterns, for example "ignores the word limit", "wrong tone for complaints", or "misses dates". Then I make one focused change aimed at the biggest pattern, such as clarifying an instruction or adding an example of that case, and rerun the full set, not just the failing case, to make sure I did not break something else. I keep each prompt version with its score so I can compare and roll back. I repeat until results are good enough for the use case, and I keep adding new failures from real usage to the test set.
Can you answer it under time pressure?
Take a timed easy round and get scored on every answer.
More easy Prompt Engineer questions
- What makes a good prompt? Walk me through how you would write one for a new task.
- When would you use zero-shot prompting and when would you add few-shot examples?
- How can you use prompting to reduce hallucinations?
- Your product team needs model output that software can read reliably. How do you design the prompt?
- Explain temperature and top-p. How would you set them for different tasks?
- Explain retrieval-augmented generation (RAG) to a non-technical colleague. Why would we use it?
- What are tokens and context windows, and why do they matter when you design prompts?
- What is chain-of-thought prompting, and when would you use it or avoid it?
- A prompt works on your demo examples but fails for some users. How do you find out why?