Structured outputs interview questions
Getting reliable JSON out of a model and validating it. Ten practice questions with answers, for AI Engineer interviews.
JSON Schema
Show answer
A standard vocabulary for describing the shape of JSON data: types, required fields, enums, nested objects and arrays.
Used to describe both tool inputs and structured outputs.
Why do apps often want JSON output from an LLM?
- So code can reliably parse and use the result
- JSON is cheaper to generate
- Models think better in JSON
- It hides the output from users
Show answer
So code can reliably parse and use the result
Free text is for humans; structured output is for programs.
Give two reasons to put a short 'reasoning' or 'evidence' field before the 'score' field in a grading schema.
Show answer
Generating the justification first lets the model think through the evidence before committing to a number, which tends to make scores more accurate and consistent. It also gives you an audit trail to debug and explain scores to users.
Field order affects generation order.
Prefill (assistant prefill)
Show answer
Starting the model's response with some text (like '{') to steer format. Some newer models don't allow it; schema-based structured outputs replace it.
Know the technique, but prefer native structured outputs where available.
Enum field
Show answer
A field restricted to a fixed set of allowed values, e.g. 'high', 'medium', 'low'.
Enums make outputs easy to branch on in code.
What does 'constrained decoding' for structured outputs do?
- Restricts which tokens can be generated so output always matches the schema
- Makes the model reason more
- Compresses the JSON
- Runs a validator after generation and retries
Show answer
Restricts which tokens can be generated so output always matches the schema
Invalid tokens are masked during generation, so the output is guaranteed parseable.
Even with schema-constrained output, why still validate with a library like Zod?
- To enforce rules the schema can't express (ranges, cross-field logic) and protect against truncation or refusals
- Zod makes the model smarter
- The API returns XML
- Validation is never needed
Show answer
To enforce rules the schema can't express (ranges, cross-field logic) and protect against truncation or refusals
Schema-valid isn't the same as correct; defence in depth.
How would you handle a structured-output response that fails validation in production?
Show answer
Check the stop reason first (refusal or max tokens mean different fixes). Log the raw output and error. Retry once, possibly with the validation error included, or with more output tokens if truncated. If it still fails, return a graceful error to the user and refund any usage. Track the failure rate in monitoring and add failing cases to your eval set.
Treat it as an expected failure mode, not an exception.
When would you choose tool use over a structured-output format to get JSON from a model?
Show answer
Use tool use when the model should decide whether and which action to take, possibly among several options, or when the JSON is an intermediate step in an agent loop. Use a structured output format when you always want a final answer in one fixed shape, such as extraction or classification.
Both produce JSON; the difference is decision-making vs fixed final output.
Your extraction schema has a required 'phone' field, and many documents have no phone. What tends to happen?
- The model may invent a plausible phone number to satisfy the schema
- The API errors
- The field is always empty string
- The model refuses
Show answer
The model may invent a plausible phone number to satisfy the schema
Make optional facts nullable and tell the model to use null when absent.
Practise these with spaced repetition and AI grading, then try a mock interview.
Start Learning Free