Interview question
How should structured output represent unknown or missing information?
Uses explicit status and field semantics so absence, null, not-applicable, and insufficient evidence are not conflated.
TL;DR
I define the meaning of absence explicitly. A missing field, null, not applicable, and unknown are different states. For important extraction tasks I often include a status such as complete, partial, or insufficientEvidence, then make nullable fields and error details consistent with that status.
Contract design for abstention and missing data instead of forcing the model to fabricate a required value.
Core answer first, then checkpoints toward a stronger answer.
Start here. This is the direct spoken answer to practice first.
If every field is required to contain a confident-looking value, the schema can pressure the model to invent one.
I define the meaning of absence explicitly. A missing field, null, not applicable, and unknown are different states. For important extraction tasks I often include a status such as complete, partial, or insufficientEvidence, then make nullable fields and error details consistent with that status.
Optional upgrade with examples, trade-offs, and sharper phrasing.
For an invoice extractor, invoiceNumber may be null because the document does not contain one, while a malformed date may be present but invalid. I would preserve the source text or location needed for review and avoid using an empty string for every exceptional case. The application checks cross-field rules before persistence.
Use these to catch weak phrasing, shallow reasoning, and risky claims.
Optional deeper angle for production judgment and nuance.
I keep request-level refusal, safety blocks, and truncation outside the normal domain result when the provider exposes them separately. That prevents a transport or policy outcome from masquerading as a business-level unknown result. For an extractor, missing source evidence produces an explicit insufficient-evidence result rather than an invented value. Metrics then distinguish legitimate abstention from missing-context defects and model regressions.
Quick interviewer prompts inside this drill.
Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.
Move to the linked follow-up, next path step, prerequisite, or deeper variant.
Move forward in the planned practice sequence.
Aporeon is shaped by Aleksandar Tomovski, a software developer with experience on both sides of technical interviews. Content is reviewed for accuracy, natural spoken delivery, useful depth, and honest trade-offs.
Help improve the interview library.
Say thanks with a standalone, one-time $5 contribution. No account required.