LangChain interview questions and answers

LangChain is an open-source framework (Python and JavaScript) for building applications on language models. It gives one interface over many model providers, plus building blocks for prompts, tools, retrieval, memory and agents, so you can switch models or vector stores without rewriting the app. In v1 the centre is create_agent, built on LangGraph, with middleware for guardrails and control.

Indexing: load documents with a loader, split them with a text splitter, embed the chunks and store them in a vector store. Querying: a retriever finds the chunks most similar to the question, they are put into the prompt as context, and the chat model answers from them, ideally citing sources. Each piece is swappable: loader, splitter, embedding model, vector store, retriever, model.

Call create_agent with a model, a list of tools and a system prompt. Tools are functions decorated with @tool (or given a schema), whose names, descriptions and argument types are sent to the model. The agent loops: the model chooses a tool call, the runtime runs it and returns the result, until the model answers. Middleware can add human approval, summarisation of long histories, PII redaction or limits on calls.

You describe each tool with a name, description and JSON schema for its arguments. The model, instead of answering in text, returns a tool call with arguments matching that schema. Your code runs the tool, sends the result back as a tool message, and the model continues until it answers. LangChain normalises this across providers with bind_tools and tool_calls on the AI message.

A chain is a fixed sequence of steps you define in code: the same path every time, predictable and cheap. An agent lets the model decide which tools to call and in what order, looping until done: flexible but less predictable and more costly. Use chains when the steps are known; use agents when the path depends on the input.

Improve retrieval first (better chunking, hybrid search, reranking), instruct the model to answer only from the provided context and say when it does not know, require citations, lower temperature, and evaluate faithfulness on a test set. Add a check step that verifies claims against the sources for high-stakes answers.

The LangChain Expression Language composes Runnables with |, so prompt | model | parser is a Runnable whose output feeds the next step. Every Runnable has invoke, batch, stream and async versions, so a composed chain streams and batches for free. It suits fixed pipelines; agents with loops are better built with create_agent or LangGraph.

Use model.with_structured_output(Schema) with a Pydantic model, TypedDict or JSON Schema. LangChain uses the provider's native structured output or tool calling, and returns a parsed object. Validation errors surface when the output does not fit, so you can retry or fall back.

Short-term memory is the message history passed to the model each turn. With agents built on LangGraph, a checkpointer stores state per thread_id, so each conversation keeps its history across requests. Long histories are trimmed or summarised (summarisation middleware) to fit the context window. Long-term memory across conversations uses a store, such as LangGraph's Store.

Split on natural boundaries (headings, paragraphs, code blocks) with RecursiveCharacterTextSplitter or a format-aware splitter, at a few hundred tokens with some overlap. Then measure retrieval quality on real questions and tune. Keep metadata such as source, page and section with each chunk for citations and filtering.

A vector store saves embeddings and runs similarity search. A retriever is the more general interface: given a query, return relevant documents. It may wrap a vector store, or combine several sources, use BM25, rerank results, filter by metadata, or rewrite the query first (multi-query, self-query).

Typed chat turns: SystemMessage sets behaviour, HumanMessage holds user input, AIMessage holds model output (including tool_calls), and ToolMessage returns a tool result linked by tool_call_id. Using typed messages keeps conversations portable across model providers.

ChatPromptTemplate.from_messages defines messages with placeholders such as {question}; MessagesPlaceholder inserts a list of messages like chat history. Invoking the template with values returns formatted messages ready for the model, keeping prompts reusable and testable.

Runnables have .with_retry() for transient failures (rate limits, timeouts) with backoff, and .with_fallbacks([...]) to try another model or chain when one fails. In agents, tool errors can be returned to the model as messages so it can correct its arguments instead of crashing.

A helper that creates a chat model from a provider-and-name string such as 'anthropic:claude-sonnet-4-5' or 'openai:gpt-5'. It lets you switch providers through configuration rather than code changes, and supports making the model configurable at runtime.

Compare candidates on your own data with a retrieval benchmark (recall@k), and weigh dimensions (storage and speed), context length, language support, cost and whether it can run locally. Never mix embeddings from different models in one index; re-embed everything when you switch.

It indexes small chunks for precise matching but returns their larger parent documents or sections to the model. This combines accurate retrieval with enough surrounding context to answer well, at the cost of more tokens per answer.

Call .stream() (or astream) on the model, chain or agent and send chunks to the client as they arrive. Agents can stream messages and intermediate steps with stream_mode options. Streaming improves perceived latency a lot, even when total time is the same.

Validate arguments with a schema, enforce permissions inside the tool (never rely on the prompt), keep tools read-only unless writes are essential, require human approval for risky actions (human-in-the-loop middleware), add timeouts and rate limits, and return clear error messages so the model can recover.

Use smaller models for easy steps such as routing, cache identical calls, cut prompt size by retrieving fewer, better chunks, stream output, run independent calls in parallel with batch or RunnableParallel, and measure each step's tokens and time in LangSmith traces.

Trace runs in LangSmith, build a dataset of real inputs with expected outputs, and run experiments with evaluators: exact checks, reference comparisons and LLM-as-judge. For RAG, evaluate retrieval (did the right chunks come back?) separately from generation (is the answer faithful?).

Rewrite the latest question into a standalone query using the history (so 'what about its price?' becomes a full question), retrieve with that query, then answer with both the retrieved context and the recent messages. Trim or summarise old history to stay within the context window.

They turn raw model text into structured data: StrOutputParser, JSON parsers and Pydantic parsers. With models that support native structured output, with_structured_output is usually better; parsers remain useful for streaming partial JSON or models without that feature.

Set a global LLM cache (in-memory, SQLite or Redis) so identical prompts return stored results, and cache embeddings with CacheBackedEmbeddings so re-indexing unchanged documents is free. Semantic caches can also match similar questions, but need a careful similarity threshold.

Map-reduce: summarise chunks independently, then combine the summaries (possibly in several rounds). Or refine: summarise the first chunk and update the summary with each following chunk. Map-reduce parallelises well; refine keeps more continuity.

RunnableParallel runs several runnables on the same input at once and returns a dict of results, such as context and question together. RunnablePassthrough forwards the input unchanged, often to keep the original question next to retrieved context.

Loaders read data from a source into Document objects with content and metadata: PDFs (PyPDFLoader), web pages (WebBaseLoader), CSV, Notion, Google Drive, databases, S3 and many more in the integrations packages.

LangChain gives model, tool and retrieval building blocks and the high-level create_agent. LangGraph is the lower-level runtime for stateful, durable graphs of steps, which LangChain agents are built on. LangSmith is the platform for tracing, evaluating and monitoring apps built with either, or with no framework at all.

Read usage_metadata on AI messages (input and output tokens), aggregate with callbacks, and use LangSmith, which records tokens and estimated cost per run so you can find expensive steps.

Pin versions, upgrade deliberately with the migration guides, keep provider integrations in their own packages, wrap LangChain usage behind your own small interfaces, and run your evaluation suite after every upgrade.

1. Acreate_agent()Correct answer
2. BAgentExecutor.run()
3. Cmake_chain()
4. Dinitialize_agent()

Why: LangChain v1 consolidates agent building into create_agent, which runs on LangGraph.

1. ACalls the model
2. BEmbeds documents
3. CBreaks documents into smaller chunksCorrect answer
4. DRanks search results

Why: Chunks small enough to match a question precisely, but big enough to carry context, are the base of good retrieval.

1. AUser passwords
2. BOnly raw PDFs
3. CEmbeddings of chunks, with their text and metadataCorrect answer
4. DModel weights

Why: Similarity search compares the query embedding with the stored chunk embeddings.

1. AHumanMessage
2. BResultMessage
3. CToolMessageCorrect answer
4. DSystemMessage

Why: It carries tool_call_id to match the request.

1. Aregister_tools
2. Bbind_toolsCorrect answer
3. Cadd_tools
4. Dwith_tools

Why: The model can then return tool calls.

1. AUse training data silently
2. BReturn an empty string
3. CSay it does not knowCorrect answer
4. DGuess confidently

Why: This reduces hallucinations.

1. AA tool
2. BA Python set
3. CA composed Runnable chainCorrect answer
4. DA vector index

Why: LCEL's pipe operator chains Runnables so each output feeds the next input.

1. Amodel.bind_prompt()
2. Bmodel.parse()
3. Cmodel.with_structured_output(Schema)Correct answer
4. Dmodel.to_json()

Why: It binds the schema using the provider's structured output or tool calling, and parses the result.

1. A@agent
2. B@toolCorrect answer
3. C@chain
4. D@retriever

Why: @tool reads the name, docstring and type hints to build the tool's schema.

1. Asave()
2. Binvoke()
3. Cstream()Correct answer
4. Dbatch()

Why: stream() yields chunks; invoke() waits for the full result.

1. A.with_retry()Correct answer
2. B.retry()
3. C.repeat()
4. D.on_error()

Why: It retries with backoff.

1. A.with_backup()
2. B.or_else()
3. C.catch()
4. D.with_fallbacks()Correct answer

Why: Fallbacks run in order.

1. AHistoryTemplate
2. BChatBuffer
3. CMemoryVariable
4. DMessagesPlaceholderCorrect answer

Why: It takes a list of messages.

1. ADownloads model weights
2. BFine-tunes a model
3. CStarts a server
4. DCreates a chat model from a provider stringCorrect answer

Why: It makes switching providers a config change.

1. AIt is slower to query
2. BIt is illegal
3. CIt uses more disk only
4. DTheir vector spaces are not comparableCorrect answer

Why: Similarity scores become meaningless.

1. AThe meaning of text as numeric vectorsCorrect answer
2. BSpelling errors
3. CFont styles
4. DFile sizes

Why: Texts with similar meaning have vectors close together.

1. AMulti-query retrieverCorrect answer
2. BParent-document retriever
3. CEnsemble of one
4. DSelf-query retriever

Why: It retrieves with each variant and merges results, improving recall.

1. AIt reduces model cost
2. BIt is required by Python
3. CIt speeds up embedding
4. DFor citations and filteringCorrect answer

Why: Metadata lets the app cite where an answer came from and filter by section, date or permission.

1. AHost the vector store
2. BChange the Python version
3. CRun custom logic around model and tool calls, such as approvals or summarising historyCorrect answer
4. DCompile prompts to C

Why: Middleware hooks into the agent loop for guardrails, human-in-the-loop, retries and context management.

1. ASkips the model
2. BCaches results
3. CStreams tokens
4. DPasses its input through unchangedCorrect answer

Why: Useful to keep the question next to context.

1. ANeeds no model calls
2. BOnly works on PDFs
3. CSummarises chunks separately, then combines themCorrect answer
4. DUses one prompt for the whole book

Why: It scales to long documents.

1. Ausage_metadataCorrect answer
2. Bresponse.tokens_only
3. Cmessage.cost
4. Dheaders.tokens

Why: It lists input and output tokens.

1. ARe-embedding unchanged textCorrect answer
2. BUsing a vector store
3. CChunking
4. DTool calls

Why: Embeddings are stored by content hash.

1. ATurns a follow-up into a standalone questionCorrect answer
2. BTranslates the answer
3. CRemoves stop words
4. DReorders documents

Why: Retrieval needs a self-contained query.

1. Alangchain-core only
2. BProvider packages such as langchain-openai or langchain-communityCorrect answer
3. Clangsmith
4. Dpydantic

Why: Integrations live in separate partner packages and langchain-community, keeping the core small.

1. AOnly fixed byte counts
2. BRandom positions
3. CA list of separators, from paragraphs down to charactersCorrect answer
4. DOnly full stops

Why: It tries larger separators first so chunks keep natural boundaries.

1. Abatch()Correct answer
2. Bfork()
3. Cspawn()
4. Dloop()

Why: batch() runs inputs in parallel with a concurrency limit.

1. AParent-document retrieverCorrect answer
2. BEnsemble retriever
3. CBM25 retriever
4. DTime-weighted retriever

Why: Small chunks match; parents give context.

1. ARunnableParallelCorrect answer
2. BRunnableSequence
3. CRunnableLambda
4. DRunnableBranch

Why: It returns a dict of results.

1. AStrOutputParserCorrect answer
2. BJsonOutputParser
3. CPydanticOutputParser
4. DXMLOutputParser

Why: It extracts the message content.