Document AI interview questions
Document AI questions a AI engineer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
Two PDFs look identical on screen, but your parser gets clean text from one and nothing from the other. Why, and what does ingestion need?
The strongest answer: One has a text layer; the other is a scan — page images — and needs OCR or a vision model first. Check per page: files mix both, and a text layer can itself be bad OCR
Why it works: Right — “PDF” says nothing about whether there is text inside. Per-page detection matters because real files mix typed pages, scans and poor text layers.
- A PDF may hold text or only pictures.
- Detect a text layer per page.
- Scans need OCR or a vision model.
- Never drop failed files silently.
Why is “just extract the text from the PDF” harder than it sounds?
The strongest answer: A PDF stores characters at positions, not paragraphs. Reading order, columns, headers and footers, hyphenation and tables must be reconstructed, and naive extraction interleaves columns — so inspect the output before building on it
Why it works: Exactly — PDF is a page-description format. Structure is something the parser infers, which is why two-column papers and tables come out scrambled.
- PDF stores positions, not structure.
- Reading order and columns are inferred.
- Strip running headers and footers.
- Read the extracted text yourself.
Your document Q&A is good on prose but wrong on figures that come from tables. In the extracted text, a table appears as one long run of numbers.
What do you change?
The strongest answer: Flattening lost which number sits under which header. Use a layout-aware parser to extract tables as rows with headers, keep each table whole with its caption, repeat headers if split, and add table questions to the evals
Why it works: Right — a table’s meaning is in its grid. Preserve headers and rows through extraction and chunking, and measure it with table questions.
- A table’s meaning is its grid.
- Extract rows with their headers.
- Keep the table and caption together.
- Test with questions about tables.
How do you chunk a long contract or manual that has headings, numbered clauses, tables and figures?
The strongest answer: Along the document’s own structure: sections and clauses as units, each carrying its heading path and page numbers as metadata, tables and lists never cut mid-way, and size-based splitting only inside sections that are too long
Why it works: Exactly — the author already divided the document for you. The heading path gives a chunk its context, and page numbers make citation possible later.
- Chunk along the document’s structure.
- Attach heading path and page numbers.
- Never cut a table or list mid-way.
- Split by size only inside long sections.
A legal team will only use your contract assistant if every answer points to a real page and clause. How do you build that?
The strongest answer: Citations come from the pipeline, not the model’s recall: chunks carry page and clause from parsing, the model cites the chunk ids it was given, and code resolves them and verifies each quote is really there
Why it works: Right — a citation is metadata you carried from the parser plus a check you ran, never a number the model typed from memory.
- Citations are carried metadata, verified.
- Keep page and clause from parsing.
- Model cites ids; code resolves them.
- Verify the quote exists in the source.
In your equipment manuals the wiring diagrams and annotated screenshots carry the key information. The text-only pipeline skips them, and answers miss what is in the figures.
What are your options, and what do they cost?
The strongest answer: Extract each figure with its caption and page. At ingestion, have a vision model write a description that is indexed and linked to the image; pass the image itself at answer time when needed, and spot-check descriptions
Why it works: Right — description at ingestion makes figures findable, the linked image keeps the evidence, and you pay once per figure instead of on every query. Sampling catches invented details.
- Figures must become findable and stay viewable.
- Extract figure, caption and page together.
- Describe at ingestion; link the original.
- Sample-check descriptions for invented details.
A customer’s legal team asked your contract assistant whether a 300-page agreement had an auto-renewal clause. It answered “no”. There was one on page 212. You own the post-mortem.
What went wrong, and what do you change?
The strongest answer: Retrieval showed the model a few chunks, so “no” meant “not in what I read”. Absence and list-everything questions need a pass over every section or a clause index built at ingestion, and answers must state their coverage
Why it works: Exactly — top-k retrieval cannot prove a negative. Route exhaustive questions to a full pass, say what was checked, and put absence questions in the evals.
- Top-k retrieval cannot prove absence.
- Route exhaustive questions to a full pass.
- State coverage in every such answer.
- Add absence questions to the evals.
Your service extracts supplier, totals and bank details from invoices in hundreds of layouts. Finance wants extracted invoices paid without a person looking at them.
What do you agree to, and what do you refuse?
The strongest answer: Auto-pay only what passes every check: schema, lines summing to the total, supplier and bank details matching master data, high confidence. Everything else goes to a reviewer shown the source region, and accuracy is tracked per field
Why it works: Right — validation against what you already know is what makes automation safe, and a changed bank account is precisely the field that never goes straight through.
- Automate only what you can verify.
- Cross-check totals and master data.
- Low confidence goes to a human.
- Show the reviewer the source region.