LangChain in Data Science interviews

What LangChain actually is

Picture the scene: you are on a Data Scientist loop at Stripe or Notion, the bar-raiser opens the LLM round, and the very first question is "walk me through how you'd wire an LLM into a production feature using LangChain." If your honest answer is "I imported langchain once in a Jupyter notebook," the next forty minutes will not be fun. LangChain is no longer a side curiosity — it is the default vocabulary interviewers use to test whether you can reason about LLM applications beyond prompt -> response.

The framework itself is a provider-agnostic abstraction layer on top of LLM APIs. It gives you four building blocks the interview will keep returning to: chains for composing calls, agents for tool routing, memory for state, and (now) LangGraph for stateful workflows. The pitch is that you can swap OpenAI for Anthropic for a local Llama checkpoint without rewriting your application logic. The reality, as we will get into, is more nuanced — and interviewers love when you can articulate exactly where the abstraction leaks.

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o-mini")
response = llm.invoke("Summarize the LangChain framework in one sentence.")
print(response.content)

That is the smallest possible "hello world." Everything else in this post is what an interviewer expects you to layer on top.

Chains

A chain is a pipeline of LLM calls (or LLM + tool + parser) with a structured input and a structured output. The modern API uses LCEL — LangChain Expression Language — and pipes components together with the | operator. Memorize the shape; you will be drawing it on the whiteboard.

from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_openai import ChatOpenAI

prompt = ChatPromptTemplate.from_template(
    "Translate the following text to {language}: {text}"
)
llm = ChatOpenAI(model="gpt-4o-mini")
chain = prompt | llm | StrOutputParser()

result = chain.invoke({"language": "French", "text": "Hello, world."})

Three things interviewers will probe. First, why LCEL and not the older LLMChain class — the answer is streaming, batching, and async come for free, plus the runnable interface lets you swap any step. Second, how do you compose chains — you pipe one chain's output dict into the next chain's input dict, often via a RunnableParallel to fan out and a RunnablePassthrough to carry context. Third, how do you handle structured output — with_structured_output(MyPydanticModel) is the modern answer; demoing function-calling under the hood scores bonus points.

This is also where most candidates blank on the difference between a chain and an agent — chains are deterministic flows, agents decide their own next step.

Agents

An agent is an LLM loop that picks a tool, executes it, observes the result, and decides what to do next. The canonical pattern is ReAct (Reason + Act), and the interviewer wants you to articulate when an agent is the right choice and when it is overkill.

from langchain.agents import create_react_agent, AgentExecutor
from langchain_core.tools import tool

@tool
def search_web(query: str) -> str:
    """Search the web for a query and return the top result."""
    return f"Top result for {query}"

@tool
def calculate(expression: str) -> str:
    """Evaluate a math expression."""
    return str(eval(expression))

tools = [search_web, calculate]
agent = create_react_agent(llm, tools, prompt)
executor = AgentExecutor(agent=agent, tools=tools, max_iterations=5)
executor.invoke({"input": "What is the current GDP of France divided by 4?"})

The pattern interviewers actually want you to flag is the failure modes. Agents can loop forever, hallucinate tool arguments, ignore observations, and run up an API bill in a single bad request. max_iterations, early_stopping_method, and strict output parsers are not optional in production — they are the safety net. If a candidate cannot name three guardrails inside two minutes, the interviewer will move on.

Memory

Memory is persistent state across LLM calls — the model itself has none, so the framework has to inject prior turns back into the prompt window. LangChain ships several variants and they are not interchangeable.

from langchain.memory import ConversationBufferMemory, ConversationSummaryMemory
from langchain.chains import ConversationChain

buffer = ConversationBufferMemory()
chain = ConversationChain(llm=llm, memory=buffer)
chain.predict(input="Hi, I'm Maya.")
chain.predict(input="What's my name?")  # buffer remembers

The interview question is "which memory type do you use when?" Reach for ConversationBufferMemory for short demos and chatbots where the full history fits in the context window. Switch to ConversationSummaryMemory once you cross roughly 20-30 turns or expect long sessions — it compresses older turns into a running summary, trading recall fidelity for token cost. For RAG-style apps where the user might reference something said a week ago, you want VectorStoreRetrieverMemory so old turns are embedded and pulled back contextually.

In LangGraph (the newer API), memory is reframed as checkpointed state — same idea, much cleaner contract. Mention this and you signal you have read more than the README.

LangGraph

LangGraph is the framework's successor for anything beyond a linear chain. It models your application as a directed graph of nodes where each node mutates a shared state object, and edges (including conditional edges) decide what runs next. The headline features versus classic agents are explicit state, durable checkpoints, and first-class human-in-the-loop support — which is exactly what production teams want and exactly what interviewers like to probe.

from typing import TypedDict
from langgraph.graph import StateGraph, START, END

class AgentState(TypedDict):
    user_input: str
    category: str
    answer: str

def classify(state: AgentState) -> AgentState:
    return {"category": "billing" if "refund" in state["user_input"] else "general"}

def handle_billing(state: AgentState) -> AgentState:
    return {"answer": "Routing you to billing support."}

def handle_general(state: AgentState) -> AgentState:
    return {"answer": "Here is a general reply."}

def route(state: AgentState) -> str:
    return "billing" if state["category"] == "billing" else "general"

builder = StateGraph(AgentState)
builder.add_node("classify", classify)
builder.add_node("billing", handle_billing)
builder.add_node("general", handle_general)
builder.add_edge(START, "classify")
builder.add_conditional_edges("classify", route, {"billing": "billing", "general": "general"})
builder.add_edge("billing", END)
builder.add_edge("general", END)

graph = builder.compile()
graph.invoke({"user_input": "I want a refund"})

In an interview, the magic phrase is "checkpointer." Pair the graph with MemorySaver() (or a Postgres checkpointer in production) and you get resumable runs, time travel, and the ability to pause for a human approval mid-workflow. This is the architectural pattern Anthropic, OpenAI, and Vercel all converged on for agentic products. If a candidate brings up checkpointing unprompted, the bar-raiser usually sits up.

Alternatives interviewers ask about

You will be asked "why LangChain and not X" — and the right answer is rarely "LangChain is best." It is "here are the tradeoffs, here is what I would pick for this problem."

The honest take: LangChain has the largest ecosystem but is repeatedly criticized for over-abstraction, frequent breaking changes, and a learning curve that punishes shallow knowledge. LangGraph is the team's response — leaner, more explicit, and the direction every serious team is moving. If you only have time to learn one thing for next week's interview, learn LangGraph plus enough LCEL to read existing code.

Common pitfalls

When candidates blow this section of the interview, the failure mode is almost always the same: they describe LangChain as if it were a model. They claim "LangChain hallucinated" or "LangChain gave a wrong answer." The fix is vocabulary discipline — the model hallucinated; LangChain is the plumbing. Interviewers notice this immediately and it tanks the technical signal.

A second common trap is defaulting to an agent when a chain would do. Agents add latency, cost, and unpredictability. If the workflow has known steps in a known order, a chain is the right answer; agents earn their keep only when the tool sequence is genuinely unknown at design time. Saying "I'd start with a chain and only escalate to an agent if I can demonstrate the routing needs to be dynamic" is the answer that scores.

The third pitfall is ignoring memory cost. ConversationBufferMemory is fine in a demo, but in a real chatbot it linearly grows token spend per turn and eventually blows the context window. Candidates who do not mention ConversationSummaryMemory, sliding windows, or vector-backed memory signal they have never shipped an LLM feature past beta. Quote a concrete number: at 16k context and 200 tokens per turn, you hit the cap around turn 80 — that is your safety margin.

A fourth, more subtle pitfall is treating the LangChain version as a free variable. The API churn between v0.0.x, v0.1, v0.2, and v0.3 has been substantial — imports moved, classes deprecated, LLMChain discouraged in favor of LCEL. If your interview code references from langchain.llms import OpenAI, the interviewer immediately knows you copy-pasted from a 2023 tutorial. Use the langchain_openai, langchain_core, langchain_community split that became standard in v0.2+.

The final pitfall is building an agent without observability. Interviewers want to hear about LangSmith, Phoenix, or even just structured logging of every tool call. "I'd wrap the executor and log inputs, outputs, latency, and token counts per step" is the bare minimum production answer.

Related reading

• AI agents in Data Science interviews
• BERT vs GPT in Data Science interviews
• Hallucinations and LLM evals
• Transformer architecture
• GPT architecture

If you want to drill LLM and agent questions like this every day with real interview prompts, NAILDD ships a structured Data Science track covering chains, agents, memory, and LangGraph patterns.

FAQ

Is LangChain still relevant in 2026, or should I just learn LangGraph?

Both. LangGraph is where serious production work is going, but LangChain (specifically LCEL — the expression-language API) is still the most ergonomic way to express deterministic pipelines, and it remains the lingua franca in interview questions. Learn LCEL well enough to read and write a three-step chain, then go deep on LangGraph for stateful workflows. Skipping LCEL leaves a gap when an interviewer hands you a legacy codebase to discuss.

What is the difference between a chain and an agent?

A chain has a fixed, known sequence of steps — the developer wires them. An agent uses an LLM to decide at runtime which tool to call next, looping until it produces a final answer. Chains are predictable, cheap, and easier to test; agents are flexible but slower, costlier, and harder to debug. The rule of thumb that scores in interviews: use a chain whenever you can describe the steps in plain English; reach for an agent only when the next step truly depends on intermediate results you cannot enumerate in advance.

Why do people criticize LangChain?

Three common complaints. First, abstraction overhead — early LangChain wrapped simple API calls in three layers of inheritance, making debugging painful. Second, API churn — frequent breaking changes across minor versions burned teams who tried to upgrade. Third, opinion drift — the "right way" to do things has changed several times (Chains -> LCEL -> LangGraph). The team has acknowledged these and the modern LCEL plus LangGraph stack is materially leaner. Interviewers want to hear you can name the criticism and the response.

When would I pick LlamaIndex over LangChain?

When the application is primarily retrieval-augmented Q&A over documents. LlamaIndex has more mature retrievers, ranking strategies, and indexing options out of the box. LangChain can do RAG too, but you assemble it from primitives; LlamaIndex gives you opinionated, batteries-included pipelines. For a system that does heavy document parsing, multi-vector retrieval, and re-ranking, LlamaIndex is often faster to ship. For a system that does conversational reasoning, tool calls, and stateful flows, stick with LangChain or LangGraph.

How do I prepare for a LangChain interview in one weekend?

Three concrete steps. Saturday morning: build a one-file LCEL chain that calls an LLM, parses structured output with Pydantic, and prints the result. Saturday afternoon: convert it to an agent with two custom tools and max_iterations=3. Sunday: rebuild the same agent as a LangGraph with three nodes, a conditional edge, and a MemorySaver checkpointer — then write down, out loud, why each piece exists. If you can explain those three artifacts on a whiteboard from memory, you will pass the LLM round at most companies.

Do interviewers actually expect me to write LangChain code on the whiteboard?

Usually not line-perfect, but yes — expect to sketch the structure. The most common asks are "draw a chain that retrieves context and generates an answer," "draw an agent with two tools," and "sketch a LangGraph with a routing node." Names matter less than the shape: nodes, edges, state object, where the LLM sits. Practice until the shape is automatic.