What makes a good prompt? Walk me through how you would write one for a new task.

What the interviewer wants to hear

• Clear goal, audience and context
• Specific instructions and constraints
• Defined output format, often with an example
• Test on varied inputs and iterate

Model answer

A good prompt is clear enough that a smart new colleague with no background could do the task. I start by understanding the goal: who will read the output and what it should achieve. Then I write the prompt in parts: the role and context, the task in plain words, important constraints like length, tone and what to avoid, and the exact output format. If the format or style is tricky, I add one or two examples. I separate any input text with clear delimiters. After that, I test it on a varied set of real inputs, not just one, and look at where it fails. Then I adjust the instruction that caused the failure and test again. I keep versions so I can compare and roll back.

More easy Prompt Engineer questions

• 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?
• Describe your process for improving a prompt that is giving mixed results.
• 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?