Chunking & document processing interview questions
7 questions across 2 sections, in the order you would learn them. Every answer here is one that works — but an answer you have read is not an answer you can give, so use Test yourself and say it out loud first.
Getting clean text out of real documents
Read the section that teaches thisIf this comes up in an interview
Why is document parsing the hard part of RAG?
Real documents are PDFs with multi-column layouts and tables, HTML full of navigation, and scans with no text layer. Extraction frequently produces the wrong reading order or loses structure, and everything downstream inherits that damage.
How do you handle tables in documents?
Extract them separately rather than letting them flatten into a run of numbers, or send the page to a multimodal model as an image. A flattened table is worse than useless because it still embeds and still retrieves.
What would you strip from HTML before indexing?
Navigation, footers, cookie banners and sidebars, because repeated boilerplate appears in every chunk and destroys the discriminating power of retrieval. Keep the heading structure, which is the most useful context available.
Splitting documents well
Read the section that teaches thisIf this comes up in an interview
Someone asks you for the best chunk size. What do you say?
That it depends on how the documents are structured and has to be measured, and that it is usually not the biggest lever available. In a comparison across four splitters on two corpora written from the same facts, section-boundary chunking was the worst strategy on documents with headings and the best on the same content written as flowing prose, because a section means something different in each. Prepending the document title and heading path before embedding moved recall further than any choice of splitter.
Then they push further
How would you run that comparison on our corpus?
Collect twenty to fifty real questions with the passage that answers each one. Chunk the corpus three or four ways, index each, and report recall at k along with the number of characters a retrieval sends, because bigger chunks buy recall by sending more text and a recall table without a cost column hides that.
What gets marked up. Marked up for refusing to give a number, naming structure as the variable, and reporting cost alongside recall.
How would you chunk documents for retrieval?
Split on structure rather than a fixed character count: sections, then paragraphs, then sentences, never mid-sentence. Around 200 to 500 tokens with a sentence or two of overlap, and prepend the document title and heading path before embedding so each chunk is self-describing.
What is the trade-off in chunk size?
Small chunks retrieve precisely but often lack the context to be useful on their own. Large chunks carry context but dilute the embedding so they match many things weakly. The right size depends on the corpus and should be measured with a retrieval eval.
Then they push further
How would you choose the size for a particular set of documents?
Try a few sizes and measure retrieval on real questions with known source passages. The best size depends on how the documents are written and what people ask, so it is found by measurement, not by a rule.
What can you do besides picking one size?
Split on structure such as headings, attach the heading path or a short document summary to each chunk before embedding, or retrieve small chunks and pass the larger surrounding section to the model.
What gets marked up. Marked up for measuring against real questions and for structure-aware chunking. A single magic number with no reasoning is marked down.
Why overlap chunks?
So an answer that straddles a boundary is not lost from both chunks. It costs a little storage and duplication and prevents a whole class of silent retrieval failure.
These are the questions for one topic. The whole question bank covers every topic on the site.