Comprehensive Interview Guide: LangChain & LangGraph Frameworks

Question 1: What is LangChain’s core purpose and what problems does it solve?

LangChain is a framework dedicated to building large‑language‑model (LLM) applications. It tackles three main problems:

Standardized encapsulation : Model calls, vector stores, and tool integrations each have different providers and APIs; LangChain wraps them behind uniform interfaces so developers do not need to manage low‑level differences.

Rapid assembly : Common functionalities are abstracted into independent components such as model interfaces, prompt templates, document loaders, text splitters, and vector stores. Developers can compose these like building blocks and create a Retrieval‑Augmented Generation (RAG) app or an Agent with only a few lines of code.

Complex workflow orchestration : Beyond basic components, LangChain offers Chains, Memory, and Agents that simplify the implementation of sophisticated tasks.

LangChain lowers the entry barrier for LLM development and is currently one of the most popular LLM frameworks.

Follow‑up : Interviewers may ask about pros and cons. Advantages include a rich ecosystem, comprehensive components, and quick onboarding. Disadvantages are heavy abstraction that hides details, fast‑changing APIs across versions, and some performance overhead in production.

Question 2: What are the five core components of LangChain?

The five core components are:

Models : Wraps various LLM and embedding models, supporting providers such as OpenAI, Anthropic, and local models, enabling seamless switching.

Prompts : Provides PromptTemplate management with variable interpolation, few‑shot examples, and chat‑message templates for structured prompt handling.

Chains : Links multiple components into an execution pipeline; the output of one component becomes the input of the next. Built‑in chains include LLMChain, RetrievalQA, SQLDatabaseChain, etc.

Memory : Manages conversational context. Implementations include BufferMemory (stores full history), SummaryMemory (summarizes), and VectorStoreMemory (vector‑based retrieval).

Tools & Agents : Tools encapsulate external functions; Agents decide autonomously whether to call a tool, which tool, and with what parameters.

These components together cover the essential stages of LLM application development.

Follow‑up : The distinction between Chain and Agent – Chain follows a fixed execution path, while Agent makes dynamic decisions at runtime.

Question 3: What is the difference between LLM and ChatModel in LangChain?

LangChain distinguishes two model interfaces to accommodate different API styles:

LLM : Traditional text‑completion model where both input and output are plain strings (e.g., early GPT‑3).

ChatModel : Conversational model that works with a list of message objects ( HumanMessage, SystemMessage, AIMessage). It supports role‑based interaction and is the mainstream choice for most applications because it enables system prompts, clear user‑assistant separation, and better context handling.

LangChain provides a unified wrapper for both, but the internal handling differs, so the choice depends on the provider’s API.

Follow‑up : When to still use an LLM? For pure text‑generation scenarios such as article continuation or code completion, especially when using older model APIs.

Question 4: What is the core RAG workflow in LangChain?

The Retrieval‑Augmented Generation (RAG) process consists of two phases:

Indexing (offline) :

Document loading – use a DocumentLoader to ingest PDFs, Word files, web pages, etc.

Text splitting – TextSplitter breaks long documents into manageable Chunk s respecting model context limits.

Vectorization – an embedding model converts each chunk into a vector.

Index storage – vectors are stored in a VectorStore together with the original text as metadata.

Query (online) :

Question vectorization – the user query is embedded with the same model.

Similarity search – the most similar document chunks are retrieved from the vector store.

Context stitching – retrieved chunks and the user question are concatenated into a prompt.

Answer generation – the LLM generates a response based on the assembled context.

LangChain’s RetrievalQA chain bundles the last three online steps, enabling a full RAG pipeline with just a few lines of code.

Follow‑up : Choosing chunk size – consider the embedding model’s context window, retrieval granularity, and typical token limits (a few hundred tokens is usually a good trade‑off).

Question 5: What memory implementations does LangChain provide?

LangChain offers several Memory classes to handle conversational state:

ConversationBufferMemory : Stores the entire dialogue history and appends it to the prompt. Simple but can exceed context limits for long conversations.

ConversationBufferWindowMemory : Keeps only the most recent K turns via a sliding window, mitigating length issues at the cost of losing early information.

ConversationSummaryMemory : Periodically summarizes the dialogue with an LLM, compressing long histories into concise abstracts while incurring extra API calls.

VectorStoreRetrieverMemory : Persists conversation history in a vector database and retrieves relevant fragments based on the current query, suitable for long‑term memory needs.

Selection depends on conversation length, cost budget, and memory requirements; combinations are also possible.

Follow‑up : Handling conflicts between memory size and prompt length – set a max_token_limit, use ConversationSummaryMemory to compress, or apply ConversationBufferWindowMemory to truncate.

Question 6: What is LCEL and what advantages does it bring?

LCEL (LangChain Expression Language) is a declarative, pipeline‑style syntax introduced by LangChain. It uses the pipe operator | to chain components, resembling Unix pipelines.

retriever | format_docs | prompt | llm | output_parser

Advantages:

Concise syntax : Complex chain logic can be expressed in a few lines, far clearer than class inheritance.

Native streaming support : LCEL chains automatically produce streaming responses without extra configuration.

Asynchronous execution : Components can run asynchronously, improving overall performance.

Good observability : Input and output of each step are easily inspected for debugging.

Composable and reusable : Defined LCEL fragments behave like functions and can be reused across projects.

LCEL is the recommended modern way to write LangChain pipelines.

Follow‑up : Difference between LCEL and traditional Chain – LCEL is lighter, more flexible, and uses a declarative style; traditional Chains may be more mature for certain edge cases, and both can be mixed.

Question 7: How do Stuff, MapReduce, and Refine document chains differ?

All three are strategies for processing multiple document chunks in LangChain:

Stuff : Concatenates all retrieved chunks into a single prompt and calls the LLM once. Simple and cheap but limited by the model’s context window.

MapReduce : Performs a “map” step where each chunk is processed individually, then a “reduce” step aggregates the intermediate results. Handles very long documents at the cost of multiple LLM calls.

Refine : Iteratively refines an answer. Starts with the first chunk, then passes the current answer together with each subsequent chunk to the LLM for improvement. Provides strong coherence but is the most time‑consuming.

Choosing among them requires balancing document length, cost budget, and desired answer quality.

Follow‑up : Implementation of the Reduce stage in MapReduce – concatenate or summarize the intermediate answers and feed them to the LLM for the final response, optionally using recursive reduction.

Question 8: How does a LangChain Agent work?

The core idea is to let the LLM make autonomous decisions:

Receive user input, combine it with conversation history and tool descriptions, and construct a prompt for the LLM.

The LLM decides whether to answer directly or to invoke a tool. If a tool is needed, it outputs a ReAct ‑style response containing Thought (reasoning) and Action (tool call).

The framework parses the Action, extracts the tool name and parameters, executes the corresponding function, and captures the Observation (result).

The observation is appended to the context, and the updated prompt is sent back to the LLM for the next reasoning step.

Steps repeat until the LLM produces a final answer.

LangChain ships with several pre‑built agents, such as zero-shot-react-description for general tasks and structured-chat-zero-shot for multi‑parameter tool calls.

Follow‑up : If a tool call fails, the framework captures the exception, feeds the error message back as an observation, and lets the LLM decide whether to retry, choose a different tool, or answer directly.

Question 9: How to define a custom tool in LangChain?

Two approaches are provided:

Decorator @tool (recommended for simplicity):

@tool
def search_api(query: str) -> str:
    """Search API – returns results for the given query"""
    return requests.get(f"https://api.example.com/search?q={query}").text

Subclassing BaseTool for finer control:

class SearchTool(BaseTool):
    name = "search"
    description = "搜索工具"
    args_schema = SearchInput

    def _run(self, query: str) -> str:
        return requests.get(f"https://api.example.com/search?q={query}").text

After defining tools, pass the list to an Agent so it can invoke them at runtime. Tool descriptions must clearly state functionality, parameters, return format, and usage scenarios for reliable LLM selection.

Follow‑up : Writing effective tool descriptions – be explicit about purpose, argument meaning, and output format.

Question 10: What is the biggest difference between LangGraph and a LangChain Chain?

The distinction lies in the architectural paradigm:

LangChain Chain : Linear, chain‑style execution where data flows from component A to B to C. Suitable for fixed, sequential pipelines.

LangGraph : Graph‑based execution supporting complex branching, loops, and parallelism. Nodes represent processing steps; edges define flow, with conditional edges enabling dynamic routing based on state.

Analogy: a Chain is a straight assembly line; a Graph is a road network where vehicles can choose routes, loop, or travel concurrently.

Follow‑up : Scenarios best suited for LangGraph – multi‑step approval processes, multi‑agent collaboration, iterative generate‑evaluate‑refine loops, and any workflow requiring conditional branching or cycles.

Question 11: What are the three core concepts of LangGraph?

State : A globally shared TypedDict that holds messages, intermediate variables, and control flags. All nodes can read and write to it.

Node : The smallest executable unit (function call, LLM call, tool execution). It receives the current State and returns an updated State.

Edge : Defines the transition rule between nodes. Ordinary edges are unconditional; conditional edges evaluate a function on State and map the returned string to the next node, enabling branching logic.

Together they provide a complete workflow orchestration capability.

Follow‑up : Designing the State structure – use TypedDict to declare explicit fields such as messages, result, is_complete, etc., according to the business needs.

Question 12: What is a StateGraph in LangGraph?

A StateGraph is the canvas that defines the entire graph:

Define the State TypedDict.

Add nodes via add_node, each bound to a processing function.

Configure edges with add_edge (ordinary) and add_conditional_edges (conditional).

Compile the graph with compile() to obtain a runnable instance.

It enables a clear, declarative definition of complex workflows.

Follow‑up : Difference from a generic graph – StateGraph emphasizes a shared mutable state that all nodes can access, whereas a plain graph may only describe connectivity.

Question 13: What are conditional edges and how to use them?

Conditional edges enable dynamic branching based on the current State:

Source node : The node from which the conditional edge originates.

Condition function : Receives State and returns a string identifier.

Mapping dictionary : Maps each possible identifier to a target node.

Example (approval workflow): the condition checks State["approval"]; if "approved" it routes to the end node, otherwise to a modification node.

Condition functions must be pure (depend only on State) to ensure predictability.

Follow‑up : Difference from RouterChain – conditional edges operate at the graph level, offering richer flow control than the chain‑internal router.

Question 14: How does LangGraph implement loops and iteration?

Loops are created by adding an edge that points back to a previously executed node, forming a cycle:

graph.add_edge("generate", "evaluate")  # generate → evaluate
graph.add_edge("evaluate", "generate")   # evaluate → generate (loop)

To avoid infinite loops, the State typically contains a counter or a flag (e.g., retry_count, is_complete). A conditional edge checks these fields and decides whether to continue looping or exit.

Typical use cases include generate‑evaluate‑refine cycles for code generation, content creation, or any task requiring iterative improvement.

Follow‑up : Preventing endless loops – set a maximum iteration count or a timeout, and let the condition function break the cycle when the limit is reached.

Question 15: How to achieve multi‑agent collaboration with LangGraph?

Typical pattern:

Define each Agent as a separate Node (could be a LangChain Agent or custom logic).

Design a shared State that includes a message list, task assignment fields, and per‑agent intermediate results.

Orchestrate execution with edges:

Conditional edges route the task to the appropriate Agent based on State (e.g., question type).

Ordinary edges define the order of Agent execution.

Common collaboration patterns:

Supervisor mode : A supervisor Agent assigns work to worker Agents and aggregates their outputs.

Pipeline mode : Agents process data sequentially, each feeding its result to the next.

Negotiation mode : Multiple Agents exchange information via State until consensus is reached.

Communication is performed by reading and writing shared State fields or appending messages to a common list.

Follow‑up : Choosing a collaboration pattern depends on task complexity, need for parallelism, and whether a central coordinator is required.

Question 16: What is LangGraph’s persistence mechanism?

Persistence saves the graph’s State and session history, enabling checkpoint‑based fault tolerance and session restoration.

Checkpoint : At designated nodes, the current State is stored in a backend.

Supported backends :

In‑memory (development only).

SQLite (lightweight local file).

PostgreSQL / Redis (production‑grade, distributed).

Benefits:

Fault recovery – resume from the last checkpoint after a crash.

Historical replay – inspect any previous State for debugging or audit.

Session continuity – preserve user conversation across restarts.

Checkpoint frequency can be tuned to balance I/O overhead against recovery granularity.

Follow‑up : Performance impact – configure checkpoint strategy (e.g., only on critical nodes, asynchronous writes) to minimize latency.

Question 17: What is the complete execution flow of a LangGraph?

Define State : Use a TypedDict to declare the global data structure.

Initialize StateGraph : Create a StateGraph instance bound to the State type.

Register Nodes : Add each processing node with add_node, linking it to a handler function.

Configure Edges : Set the entry node, add ordinary edges with add_edge, and conditional edges with add_conditional_edges to form the full workflow.

Compile the Graph : Call compile() to transform the declarative definition into an executable object.

Trigger Execution : Provide an initial State and invoke invoke() (synchronous) or stream() (streaming) to start the run. Nodes are traversed according to edge rules until an end node is reached, and the final State is returned.

Follow‑up : Difference between invoke and stream – invoke blocks until the whole graph finishes, while stream yields intermediate node outputs in real time, useful for UI feedback.

Question 18: How do LangChain and LlamaIndex differ and when to choose each?

Both are LLM application frameworks but focus on different aspects:

LangChain – a general‑purpose toolkit covering model calls, prompt management, chain composition, agents, tool integration, and more. It offers maximal flexibility for building arbitrary LLM‑driven systems.

LlamaIndex – specialized for Retrieval‑Augmented Generation (RAG) and knowledge‑base retrieval. It provides data loaders, index builders, and query engines with a variety of index types (vector, tree, list, keyword).

Selection guidance:

Choose LangChain for generic LLM applications that require diverse components, custom agents, or complex orchestration.

Choose LlamaIndex when the primary goal is high‑quality document retrieval and RAG, where its optimized indexing pipelines add value.

The two can be combined: use LlamaIndex for indexing/retrieval and LangChain for chain/agent orchestration.

Follow‑up : Learning curve – LangChain has a broader API surface and steeper learning curve; LlamaIndex is more focused and easier to start with for retrieval‑centric projects.