A language model returns text, but your code needs something it can act on. Structured output and tool calling are the two ways to get there. With structured output, the model returns a JSON object that matches a schema you wrote, so a router or database can read it field by field. With tool calling, the model returns a request to run one of your functions, with JSON arguments, and your code decides whether to run it. In both cases the model only produces text. Your program parses it, checks it, and does the work. Neither is needed when the output is free text a person reads, such as a drafted reply, or when a lookup is needed on every request and your code can simply run it before the call.

Interviewers usually reach this with one question: how do you get the model to return data your code can use, or to call your APIs? It is rarely a whole round. It shows up as a 5-10 minute follow-up in almost every large language model (LLM) design discussion, and a weak answer here, such as letting the model decide which customer's order it may refund, is a red flag.

We'll use one example throughout: a support-ticket assistant for an online electronics retailer. It reads about 20k customer emails a day. For each one it returns a triage record, {category, priority, order_id, wants_refund}, that routes the ticket. It can also call two tools: get_order(order_id) to look up an order and issue_refund(order_id, amount_cents) to pay money back. The first need is structured output. The second is tool calling, and it has real side effects.

For a mid-level interview, you should pick an output mode and explain who does what in a tool call. For a senior interview, you also design the validation and retry policy, the tool interfaces, and the checks that stop a duplicate or unauthorized refund. Writing good prompts is assumed here, and Prompt design covers it.