LangChain Interview Questions: Top 40 (2026)

These are the LangChain interview questions hiring managers actually ask in 2026, with model answers and code you can paste into a REPL. It is built for AI/ML engineers, LLM app developers, and senior backend engineers prepping the night before a loop at an AI startup, a FAANG GenAI team, or an AI-forward enterprise.

One thing up front. LangChain 1.0 shipped in October 2025. Agents now run on the LangGraph runtime, and the legacy chain classes you memorized in 2023 (LLMChain, SequentialChain, initialize_agent) moved to a separate langchain-classic package. If you walk in quoting those as current, a sharp interviewer will catch it. This guide flags every legacy answer and gives you the modern replacement, so you sound like someone who shipped in the last six months, not someone who read a 2023 Medium post.

A LangChain loop usually runs three to four rounds. A recruiter screen, one or two technical rounds, and a system design round for mid and senior roles.

The technical round splits by level. Junior candidates get asked to explain the building blocks: what a Runnable is, how the pipe operator composes them, how to get structured output. You should be able to write a small chain from memory. Mid-level candidates get retrieval and agents: chunking strategy, retriever types, tool calling, debugging bad RAG results. Senior and staff candidates get open-ended design probes: memory across sessions, multi-agent orchestration, cost and latency control, evaluation pipelines, and the judgment call of when not to reach for LangChain at all.

The single biggest thing to acknowledge is the LCEL to LangGraph shift. LCEL (the LangChain Expression Language, the pipe-operator composition syntax) is still alive and correct for linear pipelines. But anything with branching, loops, memory, or human-in-the-loop now lives in LangGraph. Saying "I'd use initialize_agent" is an instant tell that you stopped learning in 2023. Saying "I'd build it as a LangGraph graph with a checkpointer" is the 2026 answer.

For the broader role, pair this with our AI engineer interview questions and agentic AI interview questions.

A Runnable is the core interface that every LangChain component implements. Prompts, models, output parsers, retrievers, and entire chains are all Runnables. The contract is a standard set of methods: invoke (single input), batch (many inputs), stream (token-by-token), and the async versions ainvoke, abatch, astream. Because everything shares this interface, you can compose any two pieces with the pipe operator.

from langchain_core.prompts import ChatPromptTemplate
from langchain_anthropic import ChatAnthropic

prompt = ChatPromptTemplate.from_template("Explain {topic} in one sentence.")
model = ChatAnthropic(model="claude-sonnet-4-5")
chain = prompt | model
chain.invoke({"topic": "vector databases"})

The | operator wires the output of one Runnable into the input of the next, building a RunnableSequence. It is the same idea as a Unix pipe. prompt | model | parser means: format the prompt, send it to the model, parse the model's output. LCEL gives you streaming, batching, and async for free across the whole sequence without writing any of that plumbing yourself.

RunnableParallel runs several Runnables on the same input at once and returns a dict of their results. RunnablePassthrough forwards the input unchanged, which is how you keep the original input around while also computing something from it. They are the two pieces that make RAG chains readable.

from langchain_core.runnables import RunnableParallel, RunnablePassthrough

chain = RunnableParallel(
    context=retriever,            # fetches docs from the question
    question=RunnablePassthrough() # keeps the raw question
) | prompt | model

This is a current-as-of-2026 trap question. LLMChain, SequentialChain, and SimpleSequentialChain are legacy. They were imperative wrappers from the pre-LCEL era. As of LangChain 1.0 they live in the langchain-classic package, kept only for backward compatibility. The modern replacement for LLMChain is plain LCEL: prompt | model | parser. For multi-step flows that used to be SequentialChain, you either chain with | (linear) or build a LangGraph graph (branching, loops, state). If a candidate writes LLMChain(llm=..., prompt=...) in 2026, that is the signal an interviewer is fishing for.

LCEL is the right tool for linear, stateless pipelines: a prompt to a model to a parser, a RAG retrieve-then-answer flow, a batch transformation. It is declarative and composable. LangGraph is the right tool when you need branching, loops, persistent state across turns, parallel nodes, or human-in-the-loop pauses. The honest senior answer: reach for LCEL first because it is simpler, and graduate to LangGraph the moment you need a cycle or memory. They are not competitors. LangGraph nodes are often LCEL chains.

Use .with_fallbacks() to swap to a backup Runnable when the primary raises, and .with_retry() to retry transient failures with backoff. Both are methods on any Runnable, so they compose cleanly.

robust = primary_model.with_retry(stop_after_attempt=3).with_fallbacks([backup_model])

PromptTemplate produces a single string, which suits older completion-style models. ChatPromptTemplate produces a list of role-tagged messages (system, human, ai), which is what every modern chat model expects. In 2026 you almost always want ChatPromptTemplate. Use it to set a system message once and slot user variables in.

from langchain_core.prompts import ChatPromptTemplate

prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a terse SQL expert."),
    ("human", "Write a query for: {request}"),
])

Use FewShotChatMessagePromptTemplate. You give it a list of example input/output pairs and an example template, and it renders them into the message list ahead of the real question. For large example sets, plug in an ExampleSelector (often semantic) so only the most relevant examples are injected, which keeps token cost down.

PydanticOutputParser turns model text into a validated Pydantic object. You define a schema, the parser injects format instructions into the prompt, and it parses and validates the response. The win is type safety: you get a real object with fields, not a dict you have to guard. The risk is that the model can still emit malformed text, which is why parse-failure handling matters (see question 12).

StructuredOutputParser is the lighter option built from a list of ResponseSchema fields. It returns a dict and does no real type validation. PydanticOutputParser gives you full Pydantic validation, nested models, and type coercion. Use StructuredOutputParser for quick flat schemas, PydanticOutputParser when you need guarantees. In 2026, though, most people skip both for the next answer.

with_structured_output() is the modern, recommended way to get typed results. Instead of asking the model to format JSON in free text and then parsing it, it uses the provider's native tool/function calling to force the schema at the API level. You pass a Pydantic model or JSON schema and get a validated object back. It is more reliable than prompt-and-parse because the model is constrained by the API, not by instructions it might ignore.

from pydantic import BaseModel

class Ticket(BaseModel):
    priority: str
    summary: str

structured = model.with_structured_output(Ticket)
structured.invoke("Server is down, customers can't log in.")

Three layers. First, prefer with_structured_output so the schema is enforced by the API and failures are rare. Second, wrap a fragile parser in OutputFixingParser, which sends malformed output back to a model with the error to repair it, or RetryOutputParser, which retries with the original prompt context. Third, at the chain level, use .with_retry() and a validation step that raises on bad data so a downstream system never sees garbage. Always have a fallback path that fails loudly rather than passing a half-parsed object forward. Prompt design itself is its own interview topic; see our prompt engineering interview questions.

The classic memory classes (now in langchain-classic) were ConversationBufferMemory (stores the full transcript), ConversationBufferWindowMemory (keeps the last k turns), ConversationSummaryMemory (summarizes old turns with an LLM to save tokens), ConversationSummaryBufferMemory (a hybrid: recent turns verbatim, older turns summarized), and VectorStoreRetrieverMemory (stores turns as embeddings and retrieves the relevant ones). Know what each does, because interviewers still ask to compare them, but flag that they are legacy.

Buffer is simplest and most faithful but blows the context window on long chats. Window caps tokens by keeping only recent turns, at the cost of forgetting early context. Summary keeps long-range context cheaply but loses detail and costs an extra LLM call per update. VectorStore memory scales to very long histories by retrieving only relevant past turns, but retrieval can miss things and adds latency. The tradeoff axis is fidelity versus token cost versus latency.

RunnableWithMessageHistory was the LCEL-era bridge for stateful chat. You wrap a chain, give it a function that returns a chat history object per session_id, and it loads and saves messages around each call. It is still functional, but for new code in 2026 the recommended path is LangGraph persistence with a checkpointer, which handles history plus arbitrary state, not just a message list.

This is the memory question senior interviewers actually probe now. LangGraph has two distinct memory mechanisms:

The crisp summary: checkpointer remembers this conversation, store remembers this user. Mixing them up is a common miss.

In production you swap the in-memory checkpointer for a durable one. LangGraph ships Postgres and SQLite checkpointer implementations (PostgresSaver, SqliteSaver). For the long-term store, you use a database-backed Store so user facts survive restarts. The interview point: in-memory saver is for demos only; a process restart wipes it, so name a durable backend.

Use trim_messages to cap by token count or message count before the model call, keeping the system message and the most recent turns. For long-range recall, run a summarization node that condenses old turns into a running summary stored in state. This is the modern, explicit version of ConversationSummaryBufferMemory, but you control exactly when and how it runs inside the graph.

Here is the minimal LangGraph pattern. A checkpointer plus a thread_id is all you need for a chat that remembers its own history across calls.

from langgraph.checkpoint.memory import InMemorySaver
from langgraph.graph import StateGraph, MessagesState, START

def call_model(state: MessagesState):
    return {"messages": [model.invoke(state["messages"])]}

builder = StateGraph(MessagesState)
builder.add_node("model", call_model)
builder.add_edge(START, "model")

graph = builder.compile(checkpointer=InMemorySaver())

config = {"configurable": {"thread_id": "user-42"}}
graph.invoke({"messages": [("human", "My name is Sam.")]}, config)
graph.invoke({"messages": [("human", "What's my name?")]}, config)  # remembers Sam

Swap InMemorySaver for PostgresSaver in production. The thread_id is what scopes the memory to one conversation.

An embedding is a dense vector that captures the semantic meaning of text. Similar meanings land near each other in vector space. RAG needs embeddings because they let you find relevant documents by meaning rather than keyword match: embed the user's question, embed your documents, and retrieve the nearest vectors. In LangChain you use an Embeddings class and pass it to a vector store.

FAISS is an in-memory library, extremely fast, great for prototypes and read-heavy local use, but it is not a managed database and you handle persistence yourself. Chroma is a developer-friendly embedded vector DB, easy local setup, good for small to mid projects. pgvector is a Postgres extension, so you get vectors next to your relational data with real transactions, backups, and operational maturity. Senior answer: if the team already runs Postgres, pgvector avoids a new piece of infrastructure; reach for a dedicated vector DB only when scale or filtering demands it.

A retriever is any Runnable that takes a query string and returns relevant documents. A vector store becomes a retriever via .as_retriever(). Because it is a Runnable, it drops straight into an LCEL chain. The abstraction matters because it lets you swap retrieval strategies (vector, keyword, hybrid, multi-query) without touching the rest of the chain.

Chunking splits documents before embedding. Too large and retrieval returns noise around the answer; too small and you lose context. Start with RecursiveCharacterTextSplitter, which splits on natural boundaries (paragraphs, then sentences) and keeps an overlap so context is not cut mid-thought. Tune chunk size to your content: prose tolerates larger chunks, code and tables need structure-aware splitting. The interview signal is that you treat chunk size and overlap as tunable parameters you'd evaluate, not magic numbers.

Plain similarity search returns the k nearest vectors, which can all be near-duplicates of each other. MMR (Maximal Marginal Relevance) balances relevance against diversity, so the retrieved set covers more of the answer instead of repeating the same passage five times. Use MMR when your corpus has redundant content and you want broader coverage in the context window.

retriever = vectorstore.as_retriever(
    search_type="mmr",
    search_kwargs={"k": 5, "fetch_k": 20}
)

MultiQueryRetriever uses an LLM to rewrite the user's question into several variations, retrieves for each, and unions the results. It fixes the case where one phrasing misses relevant docs. SelfQueryRetriever uses an LLM to parse a natural-language query into both a semantic search string and a metadata filter (for example "papers after 2023 about RAG" becomes a vector search plus a year > 2023 filter). Both trade extra LLM calls and latency for better recall.

Work it as a pipeline, top to bottom. First, inspect what was retrieved before blaming the model: print the chunks and check whether the answer was even in the context. If not, the problem is retrieval, not generation. Then check chunking (chunks too big or split mid-answer), the embedding model (domain mismatch), k (too low to include the answer), and whether you need MMR or hybrid search. Add a reranker if good chunks come back but ranked low. The discipline interviewers grade: isolate retrieval from generation before touching the prompt. There is a whole round on this in our RAG interview questions.

Tool calling lets a model decide to invoke a function and return structured arguments for it, instead of replying in prose. LangChain binds tools to a model with .bind_tools(). The model returns tool_calls with a name and arguments; your code (or the agent runtime) executes them and feeds results back. This is the foundation every modern agent is built on.

The @tool decorator turns a plain function into a LangChain tool. The function name becomes the tool name, the docstring becomes the description the model reads to decide when to call it, and the type hints become the argument schema. A clear docstring is not optional; it is the model's only instruction on when to use the tool.

from langchain_core.tools import tool

@tool
def get_weather(city: str) -> str:
    """Return the current weather for a given city."""
    return weather_api.lookup(city)

ReAct (Reason + Act) is the older pattern where the model emits reasoning and actions as parsed text in a loop. It works on models without native tool support but is brittle because it depends on text parsing. Tool-calling agents use the model's native structured tool-calling API, which is more reliable and now the default. In 2026, "ReAct agent" usually refers to the loop pattern (reason, act, observe, repeat) implemented on top of native tool calling, not the old text-parsing approach.

initialize_agent is the deprecated legacy constructor; do not use it in 2026. The modern replacement is create_react_agent from LangGraph (langgraph.prebuilt). It builds a production-ready agent on the LangGraph runtime: a reason-act-observe loop with built-in state, streaming, and checkpointer support. The key difference is the runtime. The new agent is a graph, so you get persistence, human-in-the-loop, and durability that the old one never had.

from langgraph.prebuilt import create_react_agent

agent = create_react_agent(model, tools=[get_weather])
agent.invoke({"messages": [("human", "Weather in Paris?")]})

LangGraph models multi-agent systems as a graph of agent nodes with explicit edges and shared state. Common shapes: a supervisor that routes work to specialist agents and collects results, or a network where agents hand off to each other. Each agent is itself a graph or chain. The interview judgment they want: know when one agent with more tools beats two agents that need to coordinate, because coordination adds failure modes and cost. Multi-agent is a tool, not a default.

This is the LangGraph state trap senior interviewers love. In a graph, state is a typed dict. If two parallel branches both write the same state key in the same step and that key has no reducer, LangGraph raises an InvalidUpdateError because it cannot decide which write wins. The fix is to annotate the field with a reducer that says how to merge concurrent updates, for example Annotated[list, operator.add] to append both branches' outputs into one list.

import operator
from typing import Annotated
from typing_extensions import TypedDict

class State(TypedDict):
    # Without the reducer, parallel writes to `results` would error.
    results: Annotated[list, operator.add]

Knowing this signals you have actually built parallel graphs, not just demos. The first time I hit InvalidUpdateError it was on a fan-out where three retriever nodes all wrote to a single docs key, and the message gives you almost nothing to go on until you realize the fix is the reducer, not the routing. If you can describe that exact failure in an interview, you have credibly built this.

Set a recursion or step limit (recursion_limit on the config) so the graph halts after N steps instead of burning budget. Add explicit termination conditions in your routing logic, cap tool-call retries, and track cost per run. In design rounds, mention a hard budget ceiling per task. Runaway loops are the classic agent production incident.

A callback handler hooks into the lifecycle of a chain, model, or tool: events like on_llm_start, on_llm_new_token, on_tool_end, on_chain_error. You use callbacks for logging, streaming tokens to a UI, collecting token counts and cost, and tracing. LangSmith tracing is built on this callback system. You implement BaseCallbackHandler and pass it in the config.

astream streams the final output of a Runnable token by token, which is what you want for piping a model's answer to a UI. astream_events streams every intermediate event in the whole chain: each model start, each token, each tool call, each retriever hit. Use astream_events (v2) when you need to show users what an agent is doing mid-run, like "searching the web" then "reading results," not just the final text.

For plain token streaming, iterate astream and push each chunk over Server-Sent Events or a WebSocket to the frontend. For agents, iterate astream_events, filter for the event types you care about (on_chat_model_stream for tokens, on_tool_start for "calling tool X"), and render a live activity feed. The senior point: stream intermediate steps so a multi-second agent run feels responsive instead of a frozen spinner, and so users can see and trust what the agent did.

LangSmith is LangChain's observability and evaluation platform. Tracing records every step of a run, the full tree of model calls, tool calls, retrievals, inputs, outputs, latency, and token cost, so you can see exactly what happened inside a chain or agent. You enable it with environment variables (LANGSMITH_TRACING=true and an API key); no code change to your chains. In production it is how you debug "why did the agent do that" without print statements everywhere.

You build a dataset of example inputs paired with reference outputs (curated from real traces or written by hand). Then you run your chain over the dataset and score each output with evaluators. This is offline because it runs against a fixed dataset, not live traffic, so it is repeatable. The point an interviewer wants: you can measure quality objectively before shipping, instead of eyeballing a few examples.

An LLM-as-judge evaluator uses a model to score outputs on criteria that are hard to check with exact match: correctness, relevance, helpfulness, faithfulness to retrieved context. You give the judge the input, the output, and a rubric, and it returns a score with reasoning. For regression testing, you run the eval dataset on every meaningful change (a prompt tweak, a model swap, a new retriever) and gate the deploy on the score not dropping. That turns "the new prompt feels better" into a number you can defend in review. This is the round most senior candidates underprepare for.

Several levers, and naming them is the whole answer. Caching: turn on LLM response caching so identical prompts do not re-bill, and cache embeddings with CacheBackedEmbeddings so you do not re-embed the same documents. Model routing: use a small, fast model for easy steps (routing, classification) and a strong model only where it earns its cost. Prompt caching: reuse large static context (system prompts, retrieved docs) via provider prompt caching. Streaming: stream tokens so perceived latency drops even when total time is the same. Token discipline: trim history and cap retrieved chunks. For a design round, give a number, like a per-request token budget and a cost ceiling per task.

Human-in-the-loop: LangGraph lets you pause a graph with interrupt() before a risky action (sending an email, executing a trade), surface it for human approval, and resume exactly where it stopped. This works because the checkpointer persists state, so the run can sit paused for minutes or days. Durability: the same checkpointing makes runs crash-recoverable; if a process dies mid-run, you resume from the last checkpoint instead of restarting.

When NOT to use LangChain: if your app is a single model call with a prompt, the raw provider SDK is simpler and has fewer abstractions to debug. If you mainly do document indexing and retrieval over a large corpus, LlamaIndex is more focused on that. Reach for LangChain (and LangGraph) when you have real orchestration: multiple steps, tools, branching, memory, and you want the observability and the standard interface. Showing this judgment, that you would skip the framework for a one-shot call, is exactly the maturity senior interviewers are checking for.

If you remember one table, remember this one. It maps the legacy APIs that competitor guides still teach to what you should say in 2026.

Drop any of these "modern" terms into an answer and you read as current. Quote the left column as live and you read as stale.

Reading this list once is not enough. The technical round makes you write a chain live, and the design round makes you defend tradeoffs out loud under follow-up questions. Both need reps.

A drilling workflow that works: pick one section a day, close the page, and rebuild the code from memory in a REPL. Then do the design probes out loud as if someone is across the table, because explaining "store versus checkpointer" cold is very different from recognizing the answer when you read it. Build one real artifact, a small RAG agent on LangGraph with a checkpointer and LangSmith tracing, and you will have a concrete project to reference when they ask "tell me about something you built."

For the meta-skill of using AI in the room, see how to ace your interview with AI, and for the broader ML rounds, machine learning interview questions and Claude Code interview questions.

Yes, but learn the current version. LangChain 1.0 plus LangGraph is a common stack at AI startups and inside enterprises building LLM apps, and the abstractions (Runnables, retrievers, tool calling) carry over even if you later go custom. What is not worth learning is the deprecated 2023 surface (LLMChain, initialize_agent). Learn LCEL for linear flows and LangGraph for orchestration.

No. LCEL is alive and correct for linear, stateless pipelines like RAG retrieve-then-answer or batch transforms. What changed is that agents and stateful workflows moved to the LangGraph runtime in LangChain 1.0. So LCEL is not deprecated, its scope just narrowed to the pipelines it is best at, and LangGraph took over branching, loops, and memory.

LangChain is the broad toolkit (models, prompts, retrievers, tools) plus LCEL composition. LangGraph is the runtime for stateful, multi-step, agentic workflows; it is part of the LangChain ecosystem and is where agents now run. LlamaIndex is more focused on data ingestion, indexing, and retrieval over large document sets. Many teams use LlamaIndex for heavy indexing and LangChain/LangGraph for orchestration. The right answer is "depends on whether your hard problem is retrieval or orchestration."

It is the execution engine introduced as the foundation for agents in LangChain 1.0 (October 2025). It runs your app as a graph of nodes with typed state, a checkpointer for persistence, streaming, and human-in-the-loop support. When an interviewer says "LangChain 1.0 runs agents on the LangGraph runtime," this is what they mean: the old AgentExecutor loop was replaced by a durable, stateful graph.

Ready to walk into the room prepared? Full disclosure: this guide is published by Interview Coder. Interview Coder is a desktop app with 20+ stealth features, used by 100K+ engineers to rehearse and pass real technical loops. Its coding answers run on Claude Sonnet 4.6, Anthropic's latest Sonnet. Plans: Free $0, Monthly Pro $299, or Lifetime Pro $799 one-time. Start prepping with Interview Coder.