LangGraph interview questions and answers

LangGraph is a low-level framework for building stateful, long-running agents and workflows as graphs: nodes are steps, edges decide what runs next, and a shared state flows through. Use it when you need loops, branches, human approval, durable execution that survives restarts, or multiple agents, with explicit control instead of a black-box agent.

State is a typed object (TypedDict or Pydantic) shared by the graph. Nodes are functions that read the state and return updates. Edges connect nodes: normal edges always go to the next node, conditional edges call a function on the state to pick the next node. The graph is compiled, then invoked with an input state.

A node calls interrupt(payload). With a checkpointer configured, the graph saves its state and returns the interrupt to the caller. To continue, invoke the graph again with the same thread_id and Command(resume=value); the node re-runs and interrupt returns the value, such as an approval or an edited argument.

A checkpointer saves the graph state after every step, keyed by thread_id. It enables conversation memory, pausing for humans, recovering from failures, and time travel to replay or fork from an earlier checkpoint. Use an in-memory saver in development and a database-backed one (Postgres, SQLite, Redis) in production.

Model it as a graph: classify the request, route to specialist nodes (billing, orders, technical) that call tools, add an interrupt before risky actions such as refunds, and loop back for follow-ups. Use a checkpointer keyed by conversation thread_id, cap iterations, and trace everything in LangSmith.

A plain loop hides control flow inside the model. LangGraph makes steps explicit, so you can add deterministic branches, parallel work, retries, human approval and persistence, resume after failures, and test nodes individually. That control matters once an agent does real work in production.

After every super-step the checkpointer saves state. If a node fails or the process crashes, you can resume the same thread from the last checkpoint instead of restarting, and successful writes from nodes in the same step are kept so they do not rerun.

A reducer defines how a node's update is merged into a state key. By default an update replaces the value; with a reducer such as operator.add or add_messages, updates are appended or merged. add_messages appends new messages and updates existing ones by ID, which is what chat state needs. Reducers also make parallel branches safe to merge.

Add edges from one node to several nodes; they run in the same super-step, and their updates are merged with reducers. For a variable number of tasks, a conditional edge can return a list of Send objects, one per item (map-reduce), and a later node gathers the results.

Supervisor: a central agent receives the task, hands work to specialist agents and decides when the job is done; predictable and easy to trace. Swarm: agents hand off directly to each other based on what is needed next; fewer hops and more flexible, but harder to control. Both are built from nodes, shared state and handoff tools or Command.

A node can return Command(update=..., goto=...) to update the state and choose the next node in one step, which is how dynamic routing and agent handoffs are written. Command(resume=...) is also how a paused graph continues after an interrupt.

Usually a TypedDict (or Pydantic model or dataclass) listing each key, with Annotated[list, add_messages] or another reducer where updates should merge rather than overwrite. MessagesState is a ready-made state with a messages key.

A checkpointer saves one thread's state history (short-term memory). The Store is a key-value store shared across threads, organised by namespaces such as (user_id, 'memories'), for long-term memory like user preferences, and can support semantic search.

Bind tools to the model in one node, then add a ToolNode that runs the requested tools and a conditional edge (tools_condition) that goes to the tool node when the last message has tool calls and to END otherwise, with an edge back from tools to the model.

Catch expected errors and write them into state so a later node or the model can react; use node-level retry policies for transient failures; route to a fallback node on repeated failure; and rely on checkpoints so a crashed run can resume.

One round of execution in which all nodes scheduled for that step run (possibly in parallel), and their updates are applied to the state together through the reducers. A checkpoint is saved after each super-step.

While the graph is paused, call graph.update_state(config, values) (optionally as a specific node) to correct the state, then resume. The change is recorded as a new checkpoint, so the history shows what the person changed.

A compiled graph can be used as a node in another graph. Subgraphs keep a team's logic or an agent's private state encapsulated, can be reused, and can be tested on their own. They share keys with the parent state or map between different schemas.

Use graph.stream(...) with a stream_mode: values for the full state after each step, updates for each node's changes, messages for model tokens, and custom for your own events. This lets a UI show progress and partial answers while a long run continues.

Because each step is checkpointed, you can list a thread's history, inspect the state at any step, and resume from an earlier checkpoint, optionally after editing the state. It is useful for debugging and for letting users try a different branch.

Set a recursion limit in the run config, count iterations in state and route to END after a maximum, and make conditional edges check for a done condition. Trace runs to see where loops happen.

Unit-test node functions with plain state dictionaries, test routing functions separately, run the compiled graph with a fake or recorded model for deterministic integration tests, and use LangSmith datasets for end-to-end quality evaluation.

An alternative to building graphs explicitly: @entrypoint marks a workflow function and @task marks units of work. You write normal Python control flow while still getting persistence, interrupts and streaming.

Cap the recursion limit, keep agent prompts and shared state small, pass summaries instead of whole histories between agents, route simple requests to cheaper models, and stop early when a quality check passes.

Use stream_mode='messages', which yields LLM tokens with metadata about the node that produced them, so the UI can show text as it is generated even inside a larger graph.

values streams the full state after each step, updates only the changes, messages model tokens, custom your own events emitted inside nodes, and debug detailed execution events. Several modes can be combined.

Short-term memory is the thread's state (such as its messages), saved by the checkpointer for that conversation. Long-term memory is a Store shared across threads, with namespaces, for facts like user preferences that should persist between conversations.

It can run inside your own service (it is a library), or on LangGraph Platform / LangSmith Deployment, which adds a server with persistence, task queues, streaming, cron jobs and the LangGraph Studio debugger. The graph is declared in a langgraph.json config.

Compiled graphs can draw themselves as Mermaid (get_graph().draw_mermaid()) or a PNG, and LangGraph Studio shows the graph, state and runs interactively for debugging.

Run-specific settings such as thread_id, user id, model choice or other values under configurable, plus callbacks and tags. Nodes can read it to behave differently per run without putting those values in state.

1. AAgentExecutor
2. BDataFrame
3. CStateGraphCorrect answer
4. DChainGraph

Why: StateGraph(State) is the main builder in LangGraph.

1. Amodel_name
2. Bnode_id
3. Cuser_agent
4. Dthread_id in the configCorrect answer

Why: The checkpointer stores state per thread_id.

1. Ainterrupt()Correct answer
2. Bwait()
3. Chalt()
4. Dpause()

Why: interrupt() saves state and returns control to the caller until resumed.

1. AActionNode
2. BRunTools
3. CToolNodeCorrect answer
4. DToolExecutor

Why: Pair it with tools_condition.

1. AOnly on errors
2. BOnce per day
3. CAfter every super-stepCorrect answer
4. DOnly at END

Why: That is what enables resume and time travel.

1. AThe recursion limit
2. BA ToolNode
3. CThe StoreCorrect answer
4. DThe checkpointer only

Why: It is namespaced key-value storage.

1. Aadd_messagesCorrect answer
2. Bmerge_dicts
3. Cconcat_strings
4. Dreplace_messages

Why: add_messages appends new messages and updates ones with the same ID.

1. ARecompile the graph
2. Bgraph.restart()
3. Cinvoke with Command(resume=value) and the same thread_idCorrect answer
4. DDelete the checkpoint

Why: Command(resume=...) passes the answer back into the paused node.

1. Aadd_conditional_edgesCorrect answer
2. Bset_entry_point
3. Ccompile
4. Dadd_edge

Why: A conditional edge's routing function returns the next node name.

1. ATask
2. BSendCorrect answer
3. CFork
4. DSpawn

Why: Returning a list of Send(node, payload) runs the node once per payload in parallel.

1. AHistoryState
2. BMessagesStateCorrect answer
3. CChatState
4. DAgentState only

Why: It uses the add_messages reducer.

1. Aroute_tools
2. Bshould_continue_builtin
3. Ctool_router
4. Dtools_conditionCorrect answer

Why: It checks for tool calls.

1. Agraph.patch
2. Bgraph.reset
3. Cgraph.update_stateCorrect answer
4. Dgraph.set

Why: It records a new checkpoint.

1. AA subgraph
2. BOne round where scheduled nodes run and updates apply togetherCorrect answer
3. CA node with two edges
4. DThe first node

Why: Parallel nodes share a super-step.

1. ABoth values are kept
2. BThe first wins silently
3. CThe graph restarts
4. DAn error is raised for conflicting updatesCorrect answer

Why: Use a reducer to merge them.

1. ASTART and ENDCorrect answer
2. BENTRY and EXIT
3. CINIT and DONE
4. DBEGIN and STOP

Why: START and END are imported constants used in edges.

1. ARedisSaver
2. BPostgresSaver
3. CInMemorySaver (MemorySaver)Correct answer
4. DSqliteSaver with a file

Why: In-memory state is lost when the process restarts.

1. AIt runs on another thread
2. BIt is skipped
3. CIt runs againCorrect answer
4. DIt throws an error

Why: The node restarts from the top on resume, so side effects should come after the interrupt or be idempotent.

1. Amessages
2. Bdebug
3. Cvalues
4. DupdatesCorrect answer

Why: updates streams the update each node returned.

1. A@graph and @node
2. B@flow and @step
3. C@agent and @tool
4. D@entrypoint and @taskCorrect answer

Why: Normal Python with persistence.

1. Avalues
2. Bdebug
3. Cupdates
4. DcustomCorrect answer

Why: Use a stream writer.

1. AThe graph's name
2. BEnvironment variables only
3. Cconfigurable in the run configCorrect answer
4. DGlobal variables

Why: Nodes read them from config.

1. Amessages
2. Bcustom
3. CvaluesCorrect answer
4. Dupdates

Why: updates yields only changes.

1. AGraphRecursionErrorCorrect answer
2. BTimeoutError
3. CLoopError
4. DStackOverflow

Why: Raise the limit or fix the loop.

1. AMore nodes
2. BStreaming
3. CThe recursion limitCorrect answer
4. DA higher temperature

Why: Exceeding the recursion limit raises an error and ends the run.

1. AA new graph
2. BA partial state updateCorrect answer
3. CA database connection
4. DNothing ever

Why: Nodes return updates for some state keys, merged by reducers.

1. ALangGraph StudioCorrect answer
2. BJupyter only
3. CPostman
4. DGrafana

Why: Studio shows the graph, each step's state and lets you rerun from a checkpoint.

1. AOnly in Figma
2. BAs SQL
3. CIt cannot
4. DAs Mermaid or PNGCorrect answer

Why: get_graph().draw_mermaid().

1. APostgreSQLCorrect answer
2. BlocalStorage
3. CCSV files
4. DRedis Pub/Sub only

Why: PostgresSaver persists checkpoints durably.

1. AA reducer
2. BA Send
3. CA retry policyCorrect answer
4. DA second START

Why: Retry policies handle transient errors.