LangChain Interview Questions

A curated set of LangChain interview questions covering the distinctions that come up when discussing framework-based LLM application design.

Fundamentals#

Q: What's the difference between a chain and an agent? A chain follows a fixed sequence of steps every time — prompt, then model, then parser, always in that order, regardless of the specific input. An agent is given a set of tools and decides at runtime which ones to use, in what order, and when it has enough information to give a final answer — the sequence of steps isn't predetermined; the model decides it dynamically based on the request and intermediate results.

Q: Why use a framework like LangChain instead of calling the model's API directly? Real LLM applications need more than a single prompt-in/text-out call — prompt templating, output parsing, retrieval integration, conversation memory, and multi-step orchestration. Writing all of that by hand for every project means re-solving the same plumbing repeatedly, in ways that are easy to get subtly wrong. A framework standardizes these pieces behind consistent, composable interfaces, though for a genuinely single simple call, calling the API directly is often the more appropriate, lower-overhead choice.

Q: How does memory work in a conversational chain? Memory keeps track of prior conversation turns (or a summary of them) and reinjects that history into the prompt on each new turn, so the model has the relevant context of what was already discussed rather than treating every message as an isolated, context-free request. Since context windows are limited, memory implementations vary — from including the full raw conversation history, to summarizing older turns to keep prompt size manageable as a conversation grows long.

Q: Explain tool calling in the context of an agent. The agent is given descriptions of available tools (name, purpose, expected arguments) and, instead of answering directly, can output a structured request naming which tool to call and with what arguments. The application (not the model) actually executes that tool and returns the real result back into the model's context, which the model then reasons over to decide its next step or produce a final answer. This lets the model take real actions — searching, calculating, querying a database — without ever directly touching those systems itself.

Q: When would you choose a simple chain over building an agent? When the sequence of steps needed to complete the task is always the same, regardless of the specific input — for example, "translate this text" or "summarize then translate" always follow the same two fixed steps. Agents add real value (and real unpredictability, latency, and cost) specifically when the right sequence of actions genuinely depends on the request and can't be known in advance; for a fixed, well-defined pipeline, a plain chain is simpler, faster, cheaper, and easier to debug.

Memory and retrieval#

Q: What's the difference between window memory and summary memory, and when would you pick one over the other? Window memory keeps only the last N raw turns and drops anything older entirely — simple and bounded, but a reference to something discussed earlier than the window silently stops resolving. Summary memory periodically compresses older turns into a running summary (itself generated via an extra LLM call) instead of dropping them, keeping some memory of old context indefinitely at the cost of losing exact wording. Window memory suits short, transactional conversations; summary memory suits long-running conversations where some memory of earlier context still matters.

Q: How does a retriever fit into a LangChain chain built with the | pipe operator? A retriever exposes the same standard interface regardless of the underlying vector store — give it a query string, get back a list of relevant documents — so it composes into a chain exactly like a prompt template or model does. A typical RAG chain runs the retriever and a pass-through of the raw question in parallel (as a dictionary of branches), formats the retrieved documents into a text block, and feeds both into a prompt template, which flows into the model and parser as usual.

Production and observability#

Q: Why is retrying every failed LLM call automatically not always the right approach? Retries help specifically with transient, infrastructure-level failures — a momentary rate limit or dropped connection — that have a real chance of succeeding on a second attempt. A failure caused by the request's own content (an invalid argument, a prompt that violates a content policy) will fail identically every time, so retrying it just wastes time and money before failing anyway; that class of error should fail fast with a clear message instead.

Q: Why does streaming matter for a chain's user-facing latency, given that it doesn't reduce total generation time? Streaming changes when the user starts seeing output, not how long the model takes to fully generate a response. A response that appears token by token, starting almost immediately, is perceived as far more responsive than one that appears all at once after the same total wait — which is usually what actually matters for a chat-style, interactive product's perceived performance.

Q: What's the value of tracing a chain's execution instead of just checking its final output? A multi-step chain has many places a problem can originate — a bad retrieval, a memory step dropping needed context, a prompt template rendering incorrectly, an agent picking the wrong tool — and the final output alone doesn't say which. Tracing captures each step's actual input and output, turning "the answer was wrong, somewhere" into a specific, actionable finding, like "the retriever returned zero relevant chunks for this query."