"How would you write the prompt for this task, and how would you improve it?" Almost every AI engineer or forward-deployed engineer design round asks some version of that question, usually right after you pick a model.

Prompt design is the answer: writing the text your application sends to a pretrained large language model (LLM) so it does the task the same way on every input, and then managing that text as a versioned artifact you test before you change it. The prompt is the main lever you have over a model you call through an API, long before anyone talks about fine-tuning. It is not the whole answer when the model lacks facts (that calls for retrieval), when code needs output guaranteed to match a schema (structured output), or when a stable behavior gap survives every prompt fix (fine-tuning).

Interviewers rarely spend more than 5-10 minutes on prompt wording, so this is a moderate-weight topic. What they listen for is whether you treat the prompt as something you test. A mid-level answer splits the prompt sensibly, states the task and output format explicitly, and knows when to add examples. A senior answer also explains how examples bias labels, what a reasoning request costs, and how a test set blocks regressions, ideally before the interviewer asks.

The running example is a help-desk assistant for a project-management app. For each of about 3,000 tickets a day, the model assigns one category (billing, bug, how_to, or account), marks urgency as high or normal, and drafts a short first reply for a human agent. One engineer owns the prompt and checks it against 40 hand-labeled tickets. A version's score is how many of the 40 get the right category. Urgency is counted separately as tickets marked high (8 in the labels). Retrieved documents in the prompt belong to Retrieval-Augmented Generation.