Describe a challenging prompt you designed in the past. What made it challenging, and how did you overcome the difficulties?

Interviewers want a specific story that shows how you think: what the goal was, why it was hard, what you tried, how you measured it and what you learned. Use the STAR structure (situation, task, action, result) and give numbers. Here is an example of a strong answer.

Situation An operations team received thousands of supplier invoices a month as PDFs in many layouts and several languages. Staff typed the key fields into the finance system by hand.

Task Design a prompt that extracted supplier name, invoice number, dates, line items, tax and totals into JSON that the finance system could import, with at least 98% of fields correct, because errors meant wrong payments.

What made it challenging

• Layouts varied widely, and some invoices spread line items over several pages.
• Dates came in different formats (03/04 is March in some countries and April in others).
• Totals sometimes didn't match the line items, and the model would "fix" them by inventing values.
• Some fields were simply missing, and early versions filled them with plausible guesses.
• Any parsing failure stopped the import.

Actions

1. Built a test set of 300 real invoices covering every supplier type and language, with fields checked by the finance team.
2. Used the API's structured outputs with a JSON schema, which removed parsing failures entirely.
3. Rewrote the instructions to copy values exactly as printed, return null for missing fields, and never calculate or correct values.
4. Added the supplier's country to the input so dates could be read correctly, and asked for dates in ISO format.
5. Moved arithmetic out of the model: code checked that line items summed to the total, and invoices that failed went to a person with the discrepancy highlighted.
6. Added three examples of difficult layouts, chosen from the failures.
7. Re-ran the full test set after every change and tracked accuracy per field.

Result Field accuracy rose from about 85% with the first prompt to over 98%, with the remaining cases routed to review. Manual entry time fell by roughly three quarters.

What I learned

• Let the model do what it is good at (reading varied layouts) and code do the rest (arithmetic, validation).
• Giving the model permission to return null reduced invented values more than any other change.
• A labelled test set turned arguments about wording into measurable decisions.

When you answer, use your own project. If you're early in your career, a personal or course project is fine, as long as you can explain the difficulty, your reasoning and how you knew it worked.