LangChain aur LangGraph interview questions & answers

Ek car wash socho: teri dusty car ek end se andar jaati hai, aur ek series of connected stations — soap, scrub, rinse, dry — har station agli station ko automatically car handover kar deta hai. Tu khud car ko station se station tak nahi le jaata; stations physically ek pipe se connected hain, ek hi line me. Dirty andar, clean bahar, ek hi pass me.

LangChain me, us piped line ko chain kehte hain, aur pipe khud ek real operator hai: |. Prompt template soap station hai — ye tere raw variables leke unhe exact message me shape karta hai jo model expect karta hai. Chat model scrub station hai — ye actual thinking/generation ka kaam karta hai. Output parser dry station hai — ye model ke reply se wrapper hata ke tujhe plain text (ya structured data) de deta hai.

Ch5 me ye loop tu khud raw SDK se bana chuka hai: khud string format kiya, khud model call kiya, khud response se .content nikala. LangChain ka contribution hai us pattern ko naam dena — LCEL (LangChain Expression Language) — aur use ek composable object bana dena: chain = prompt | model | parser. Ek baar bana lo, aur .invoke() (ek input), .stream() (token-by-token), aur .batch() (multiple inputs ek saath) free me milte hain — koi extra code nahi.

Purane LangChain tutorials (0.x) chains ek class se banate the — LLMChain — aur chain.run(...) se chalate the. Dono current 1.x line me DELETE ho chuke hain — LLMChain import karte hi ModuleNotFoundError aata hai, program shuru hone se pehle hi. Agar koi tutorial LLMChain ya .run() dikhata hai, toh wo dead API sikha raha hai; | pipe hi ek chain-building pattern hai jo abhi bhi chalta hai.

🌍 Real-world example: ek support-ticket triage app raw customer message leta hai, prompt template use "classify this ticket" instruction me shape karta hai, model ek category return karta hai, aur parser model ke reply ko sirf category string tak strip kar deta hai jo tera database column expect karta hai — teen stations, ek pipe.

💡 Runnable = koi bhi cheez jiske paas .invoke(), .stream(), aur .batch() hai — ye ek interface har LangChain building block (prompts, models, parsers, chains) share karta hai.

💡 LCEL (LangChain Expression Language) = | syntax jo Runnables ko pipe karke ek bada Runnable banata hai, jise RunnableSequence kehte hain.

💡 Output parser = ek Runnable jo model ke raw reply ko us format me reshape karta hai jo tera code actually chahta hai (string, JSON, etc.).

Standard definition (interview me bolo): LangChain is a framework for composing LLM calls, built around the Runnable interface (.invoke()/.stream()/.batch()); LCEL uses the | operator to pipe Runnables — such as prompt | model | parser — into a single chain, replacing the deleted 0.x LLMChain/.run() pattern.

import os
os.environ.setdefault("OPENAI_API_KEY", "sk-...")  # normally already set, like in Ch5

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

prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a {role}."),
    ("human", "{question}")
])

model = ChatOpenAI(model="gpt-4o-mini")  # model IDs change — check the provider's current list

chain = prompt | model | StrOutputParser()

print(type(chain).__name__)
print(hasattr(chain, "invoke"), hasattr(chain, "stream"), hasattr(chain, "batch"))

try:
    from langchain.chains import LLMChain
except ModuleNotFoundError as e:
    print("LLMChain is gone:", e)

# result = chain.invoke({"role": "Python tutor", "question": "What are decorators?"})
# print(result)  # illustrative only -- needs a real API key

Factory assembly line soch. Ek box station 1 pe aata hai, ek part add hota hai, station 2 pe move karta hai, ek aur part add hota hai, station 3 pe move karta hai, aur end me finished nikalta hai. Koi box ko haath se station-to-station carry nahi karta — ek conveyor belt unko connect karti hai. Ch3/Ch4 me tune RAG haath se banaya tha: doc khud chunk kiya, khud embed kiya, khud cosine similarity nikali, phir khud prompt string bana ke model call kiya. LangChain ka kaam wahi conveyor belt banna hai — same stations, ek operator se wired.

In LangChain, wo conveyor belt hai LCEL (LangChain Expression Language): | Runnables ko connect karta hai (kuch bhi jispe .invoke()/.stream()/.batch() ho). Ek RAG chain hoti hai retriever | prompt | model | parser — ya jab retrieved docs aur raw question dono ek saath prompt me jaane chahiye, ek dict shape: {"context": retriever | format_docs, "question": RunnablePassthrough()}. Ye dict SAME input pe dono branches ko parallel me chalata hai aur unke outputs ko ek object me merge karta hai jo prompt template fill karta hai. RunnablePassthrough() ka matlab hai "input jaisa hai waisa hi le lo" — yahan, raw question ko koi transformation nahi chahiye, sirf context branch ko chahiye (retrieve karo, phir retrieved docs ko ek string me flatten karo).

Underlying RAG idea kuch nahi badalta: chunks me split karo, har chunk embed karo, vectors store karo, question ke liye closest wale retrieve karo, prompt me daalo, model se poocho. LangChain retrieval ko smart nahi banata na LLM call cheap karta hai — chain ka har node jo embedding model ya chat model call karta hai wo still ek billed API call hai, Ch3-Ch5 jaisi hi economics. Ye jo deta hai wo hai composition: vector store swap karo, streaming add karo, retries add karo, bina plumbing haath se dobara likhe.

🌍 Real-world example: Ek company policy chatbot. retriever.invoke("How many sick leaves?") HR policy doc se top-k matching chunks ko Document objects ke roop me return karta hai. format_docs unke .page_content ko ek context string me jod deta hai. Chain {context} aur {question} prompt template me bharti hai, model ko bhejti hai, aur StrOutputParser() reply ko AIMessage object se plain text tak unwrap kar deta hai — toh rag_chain.invoke("...") ek string return karta hai, koi object nahi jise dig karna pade.

💡 Runnable = kuch bhi jispe .invoke()/.stream()/.batch() ho — ek retriever, ek prompt template, ek chat model, aur ek parser sab Runnables hain, ISI WAJAH SE inko | se pipe kar sakte ho.

💡 retriever = ek vector store jo Runnable ki tarah wrap kiya gaya hai (vectorstore.as_retriever(search_kwargs={"k": N})); ise call karne pe top-k sabse similar chunks Document objects ke roop me milte hain (Ch3 ki cosine-similarity search, tere liye ready-made).

💡 RunnablePassthrough() = ek Runnable jo apna input bina badle wapas kar deta hai — tab use hota hai jab parallel step ke ek branch ko koi transformation nahi chahiye.

💡 StrOutputParser() = model ke AIMessage response ko plain string tak unwrap karta hai, taaki chain ka final .invoke() result seedha print ya UI ko bheja jaa sake.

Ek honest gotcha: langchain_community ka Chroma import (jo zyaadatar tutorials abhi bhi dikhate hain) chalta toh hai par DeprecationWarning deta hai — wo package sunset ho raha hai. Ek dedicated langchain-chroma package, ya chhote/demo data ke liye langchain_core ka InMemoryVectorStore, current tareeka hai.

Standard definition (interview me bolo): A LangChain RAG chain wires a text splitter, an embedding model, a vector store retriever, a prompt template, a chat model, and an output parser into one LCEL pipeline ({"context": retriever | format_docs, "question": RunnablePassthrough()} | prompt | model | parser) so the whole retrieve-then-generate flow runs as a single composable, streamable Runnable.

from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_core.vectorstores import InMemoryVectorStore
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough

# Step 1: split the source document into chunks (Ch3/Ch4 chunking, LangChain's splitter class)
text = """LangChain is a framework for building LLM applications.
It provides abstractions for chains, prompts, and retrievers.

RAG stands for Retrieval Augmented Generation.
It combines a retriever with a language model to answer questions using external documents.

The LangChain Expression Language (LCEL) lets you compose Runnables with the pipe operator.
This makes chains easy to read, stream, and debug."""

splitter = RecursiveCharacterTextSplitter(chunk_size=120, chunk_overlap=20)
chunks = splitter.split_text(text)
for i, c in enumerate(chunks):
    print(f"Chunk {i+1} ({len(c)} chars): {c!r}")

# Step 2: embed the chunks and store them (needs a real API key to actually run)
vectorstore = InMemoryVectorStore.from_texts(chunks, embedding=OpenAIEmbeddings())
retriever = vectorstore.as_retriever(search_kwargs={"k": 2})

# Step 3: the LCEL RAG chain
def format_docs(docs):
    return "\n\n".join(doc.page_content for doc in docs)

prompt = ChatPromptTemplate.from_template(
    "Answer based ONLY on the following context:\n\n{context}\n\nQuestion: {question}"
)
model = ChatOpenAI(model="gpt-4o-mini", temperature=0)  # model IDs change — check the provider's current list

rag_chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | prompt
    | model
    | StrOutputParser()
)
print(type(rag_chain))

answer = rag_chain.invoke("What does LCEL let you do?")
print(answer)

Kya bana rahe hain: ek AI Research Agent — ek LangGraph graph jo ek question leta hai, reason → act → observe loop chalata hai ek real web-search tool aur ek tool-calling LLM ke saath, aur ek synthesised answer return karta hai. Ye Ch5 ke haath se likhe agent loop aur Ch6 ke poore LangGraph mental model ko ek runnable project mein fuse karta hai: ek StateGraph jismein agent node (model, decide karta hai kya karna hai), tools node (ek real ToolNode, jo model ne maanga wo execute karta hai), ek conditional edge (aur search chahiye ya ho gaya?), aur ek recursion_limit taaki ye kabhi hamesha ke liye spin na kare.

---

Step 0 — Mental model (pehle padho)

User question
     │
     ▼
[agent] ──model se poochta hai: "search karna hai ya ab answer de du?"──┐
     │                                                              │
 tool_calls hai?                                              tool_calls nahi hai
     │                                                              │
     ▼                                                              ▼
 [tools] ──web_search real mein chalata hai, result append karta hai──▶ wapas [agent]     [END] — final answer

Ye EXACTLY Ch5 ka while loop hai (model call karo → tool calls check karo → execute karo → result wapas bhejo → repeat), bas ek explicit, inspectable graph ke roop mein draw kiya gaya hai, Python control flow ke andar chhupa hone ki jagah. Upar ka har arrow ek real LangGraph edge hai jo neeche likhoge.

💡 Reason → Act → Observe = model REASON karta hai ki use kya chahiye (ek LLM call), ACT karta hai ek tool call maang ke (khud tool run nahi karta), aur OBSERVE karta hai tool ka real result phir se reason karne se pehle.

---

Step 1 — Agent ko ek real tool do

from langchain_core.tools import tool

@tool
def web_search(query: str) -> str:
    """Search the web for current information on a topic and return short snippets."""
    # Real build mein ye body ek live search API call se replace hoti hai.
    # Is project ke liye ise stub rakha hai taaki WIRING zero API keys se chale.
    return f"[search stub] top result for '{query}'"

Ho ye raha hai: @tool function ka naam, docstring aur type hints inspect karta hai aur unhe ek schema mein badalta hai jo model padh sake — web_search.name, .description, .args. Ye bilkul wahi rule hai langchain-tools se: model sirf ye SCHEMA dekhta hai, function ki body kabhi nahi. Chaahe body ek real HTTP call kare search API ko, ya ek stub string return kare, model ka kaam (decide karna KAB call karna hai) nahi badalta — isiliye tum poore graph ki wiring zero API keys se verify kar sakte ho, aur sirf is ek function ki body baad mein real search call se swap karni hoti hai.

🌍 Real-world example: C:/lcv pe web_search.args print karne se {'query': {'title': 'Query', 'type': 'string'}} milta hai — wahi dict model ko dikhaya jaane wala schema HAI. Kuch chhupa nahi, kuch magic nahi.

---

Step 2 — Ek tool-calling model banao

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4.1-mini")  # model IDs change — check the provider's current list
model_with_tools = llm.bind_tools([web_search])

Ho ye raha hai: bind_tools([...]) API call nahi karta — ye ek naya Runnable return karta hai jo apni har request ke saath tool schemas ATTACH karega. ChatOpenAI(...) ko construct hone ke liye ek API-key VALUE present chahiye (real key, ya ek placeholder string / env var), kyunki ye internally ek OpenAI client object banata hai — par construct hote waqt koi network call nahi hoti aur key validate bhi nahi hoti. Sirf model ko actually invoke karne (Step 8) ke liye ek genuinely working key chahiye. Ye line C:/lcv pe ek placeholder key aur zero network activity ke saath cleanly construct hoti hai, verified.

---

Step 3 — State define karo

from typing import Annotated
from typing_extensions import TypedDict
from langgraph.graph.message import add_messages

class ResearchState(TypedDict):
    messages: Annotated[list, add_messages]

Ho ye raha hai: ek field, messages, add_messages reducer ke saath tagged. Neeche har node ek PARTIAL update return karta hai — bas naye message(s) — aur LangGraph unhe list mein REPLACE karne ki jagah APPEND karta hai. Ye tag skip karo to har tool result us question ko mita dega jisne run start kiya tha.

---

Step 4 — agent node (reason)

def agent(state: ResearchState):
    response = model_with_tools.invoke(state["messages"])
    return {"messages": [response]}

Ho ye raha hai: POORA reasoning step ek line hai — model_with_tools.invoke(...) poori message history bhejta hai aur ek AIMessage wapas leta hai. Us message mein ya to .tool_calls hoga (model search karna chahta hai) ya nahi hoga (model answer dene ke liye ready hai). Node khud koi decision nahi leta — bas model run karta hai aur uska message return karta hai; DECIDE karna Step 5 ke router mein hota hai. Ye bilkul Ch5 ka rule hai: model sirf tool call karne ki request RETURN karta hai, khud tool kabhi run nahi karta.

---

Step 5 — Router + real ToolNode (act)

from typing import Literal
from langgraph.prebuilt import ToolNode
from langgraph.graph import END

def should_continue(state: ResearchState) -> Literal["tools", "__end__"]:
    last = state["messages"][-1]
    if last.tool_calls:
        return "tools"
    return END

tool_node = ToolNode([web_search])

Ho ye raha hai: should_continue ROUTER hai — last message inspect karta hai aur ek plain string return karta hai, agle node ki key. ToolNode wo piece hai jo model ke maange tool calls ko actually EXECUTE karta hai, real Python function run karta hai, aur har result ko ek ToolMessage mein wrap karke wapas messages mein add karta hai. Ye "act" aur "observe" beats hain: ToolNode act karta hai (function real mein run karta hai), aur uska ToolMessage output wo hai jo agent node apne agle turn mein observe karta hai.

---

Step 6 — Graph wire karo

from langgraph.graph import StateGraph, START

graph = StateGraph(ResearchState)
graph.add_node("agent", agent)
graph.add_node("tools", tool_node)
graph.add_edge(START, "agent")
graph.add_conditional_edges("agent", should_continue, {"tools": "tools", END: END})
graph.add_edge("tools", "agent")

research_agent = graph.compile()

Ho ye raha hai: START → agent hamesha pehle chalta hai. agent se, add_conditional_edges should_continue ke return value pe branch karta hai: "tools" tools node pe route karta hai, END graph ko rok deta hai. tools → agent loop close karta hai — har tool result seedha agent ko wapas jaata hai agle reasoning pass ke liye. .compile() is wiring ko ek Runnable mein badalta hai .invoke() ke saath. C:/lcv pe verified: ye exact graph ek placeholder API-key value aur zero network calls ke saath compile hota hai — ChatOpenAI ko client object banane ke liye key VALUE present chahiye, par na construction na .compile() kabhi network touch karte; sirf Step 8 ka .invoke() karta.

---

Step 7 — Wiring ko bina API key ke prove karo

Ek real model pe trust karne se pehle, graph ki STRUCTURE ek placeholder agent node se prove karo jo haath se wahi message shapes return karta hai jo ek real tool-calling model deta:

from langchain_core.messages import AIMessage, HumanMessage

_turn = {"n": 0}
def stub_agent(state: ResearchState):
    _turn["n"] += 1
    if _turn["n"] == 1:
        return {"messages": [AIMessage(content="", tool_calls=[
            {"name": "web_search", "args": {"query": "LangGraph recursion_limit"}, "id": "call_1"}
        ])]}
    return {"messages": [AIMessage(content="Final synthesised answer using the real tool result.")]}

stub_graph = StateGraph(ResearchState)
stub_graph.add_node("agent", stub_agent)
stub_graph.add_node("tools", tool_node)
stub_graph.add_edge(START, "agent")
stub_graph.add_conditional_edges("agent", should_continue, {"tools": "tools", END: END})
stub_graph.add_edge("tools", "agent")
stub_app = stub_graph.compile()

result = stub_app.invoke(
    {"messages": [HumanMessage(content="How does LangGraph stop an agent from looping forever?")]},
    {"recursion_limit": 10}
)
for m in result["messages"]:
    print(type(m).__name__, "|", getattr(m, "content", m)[:60])

Ye C:/lcv pe ACTUALLY chala — zero API keys — aur bilkul ye state transition diya, message by message:

[0] HumanMessage: 'How does LangGraph stop an agent from looping forever?'
[1] AIMessage: ''  tool_calls=[{'name': 'web_search', 'args': {'query': 'LangGraph recursion_limit'}, ...}]
[2] ToolMessage: "[search stub] top result for 'LangGraph recursion_limit'"
[3] AIMessage: 'Final synthesised answer using the real tool result.'

Beat by beat trace karo: [0] question state mein enter ho raha hai. [1] agent ka PEHLA reasoning pass hai — usne decide kiya ki search chahiye, to should_continue ne "tools" pe route kiya. [2] REAL ToolNode hai jo actually web_search(query="LangGraph recursion_limit") call kar raha hai aur uska genuine return value ek ToolMessage ke roop mein append kar raha hai — is part ne real tool function use kiya, stub nahi. [3] agent ka DOOSRA reasoning pass hai: is baar returned AIMessage mein tool_calls nahi hai, to should_continue ne END return kiya aur graph ruk gaya. Chaar messages aaye, chaaron bache — add_messages ne har ek ko append kiya, kabhi overwrite nahi kiya.

---

Step 8 — Real, model-backed run (illustrative)

stub_agent ko wapas Step 4 ke real agent node se swap karo (model_with_tools.invoke(...)) aur tumhare paas research_agent hai Step 6 se. Ek real OPENAI_API_KEY ke saath, ise call karna SHAPE mein Step 7 ke proven trace jaisa hi dikhega — bas ab [1] ka tool call aur [3] ka final answer genuinely model se generate hote hain, haath se likhe nahi:

result = research_agent.invoke(
    {"messages": [("user", "What is LangGraph's recursion_limit and why does it matter?")]},
    {"recursion_limit": 10}
)
print(result["messages"][-1].content)

⚠️ Illustrative — ise author karne ke liye koi live key use nahi hui. Message ki SEQUENCE (Human → AI-with-tool-call → Tool → AI-final) real verified hai, kyunki Step 7 ne exact wahi routing exact wahi graph ke saath chalayi. Sirf model ke tool-call arguments aur final answer ki WORDING neeche illustrative hai, jo real web_search tool se jo poocha aur mila hota uske consistent rakhi gayi hai:

AI (illustrative): The recursion_limit config value caps how many super-steps a
LangGraph run can take. Once an agent loop exceeds it, LangGraph raises a
GraphRecursionError instead of looping forever, which matters because an agent
that never routes to END would otherwise call the model — and the search tool —
indefinitely, burning tokens and API quota on every extra pass.

---

Step 9 — Loop ko real mein bound karo

try:
    research_agent.invoke({"messages": [("user", "loop forever")]}, {"recursion_limit": 6})
except Exception as e:
    print(type(e).__name__, str(e)[:80])

Ye C:/lcv pe test kiya gaya, ek graph ke saath jo kabhi END pe route nahi karta (ek router jo hamesha "tools" return karne ke liye hard-coded hai), aur isne ek real GraphRecursionError: Recursion limit of 6 reached without hitting a stop condition. diya — koi hang nahi, koi silent failure nahi. Isiliye recursion_limit optional polish nahi hai: kisi bhi agent graph mein router bug ho (ya genuinely confused model jo tool request karta rahe), ye loudly bound hota hai, aur tumhara API bill chupke se infinite loop mein nahi badhta.

---

✅ Jo tumne abhi banaya — aur resume framing

Tumne ek graph banaya jo: @tool se ek real tool define karta hai, ise ek tool-calling model se bind karta hai, conversation state ko sahi add_messages reducer se track karta hai, ek real conditional edge se route karta hai, ek real ToolNode se tool calls execute karta hai, reason→act→observe loop chalata hai jab tak model done na ho, aur recursion_limit se bound hai taaki kabhi run away na kare. Ye ek legitimate LangGraph agent hai, toy nahi — SAME shape (agent node + tools node + conditional edge + loop-back edge) hai jo create_react_agent(model, tools) (note: LangGraph 1.0 se deprecated, langchain.agents.create_agent iska successor hai, par ye naam abhi bhi chalta hai aur zyadatar tutorials isi ka use karte hain) tumhe prebuilt deta hai; ab tumhe exactly pata hai ye under the hood kya karta hai kyunki tumne ise haath se wire kiya.

Resume/interview ke liye: "Built an AI research agent in LangGraph — a StateGraph implementing a reason-act-observe loop with a real tool-calling model, a ToolNode executing web search, conditional routing between reasoning and tool execution, and a bounded recursion_limit to prevent runaway agent loops." Ye sentence dikhata hai ki tum agent architecture samajhte ho, sirf ek API call kiya nahi.

Ise extend karne ke liye bonus features (project claim karne ke liye teenon banana zaroori NAHI hai):

1. Multiple tools — web_search ke saath ek calculator tool add karo; ToolNode already handle karta hai model ek turn mein kai tool calls maange, koi wiring change nahi chahiye.
2. Human-in-the-loop — tools node se pehle interrupt() daalo taaki koi insaan search approve kare chalne se pehle, MemorySaver checkpointer aur ek thread_id ke saath compile kiya hua (dekho human-in-the-loop).
3. Streaming — research_agent pe .invoke() ki jagah .stream() use karo taaki har node ka output ho hote hi print ho, poore run khatam hone ka wait kiye bina.

Standard definition (interview me bolo): an AI research agent is a LangGraph StateGraph that implements the reason-act-observe agent loop as an explicit graph — a tool-binding model node that reasons and requests tool calls, a ToolNode that acts by executing them for real, a conditional edge that routes between reasoning and acting until the model signals it is done, and a recursion_limit that bounds the loop against runaway execution.

from typing import Annotated, Literal
from typing_extensions import TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.graph.message import add_messages
from langgraph.prebuilt import ToolNode
from langchain_core.tools import tool
from langchain_openai import ChatOpenAI

@tool
def web_search(query: str) -> str:
    """Search the web for current information on a topic and return short snippets."""
    # A real build swaps this body for a live search API call.
    return f"[search stub] top result for '{query}'"

llm = ChatOpenAI(model="gpt-4.1-mini")  # model IDs change — check the provider's current list
model_with_tools = llm.bind_tools([web_search])

class ResearchState(TypedDict):
    messages: Annotated[list, add_messages]  # reducer: APPENDS, never overwrites

def agent(state: ResearchState):
    response = model_with_tools.invoke(state["messages"])
    return {"messages": [response]}

def should_continue(state: ResearchState) -> Literal["tools", "__end__"]:
    last = state["messages"][-1]
    if last.tool_calls:
        return "tools"
    return END

tool_node = ToolNode([web_search])

graph = StateGraph(ResearchState)
graph.add_node("agent", agent)
graph.add_node("tools", tool_node)
graph.add_edge(START, "agent")
graph.add_conditional_edges("agent", should_continue, {"tools": "tools", END: END})
graph.add_edge("tools", "agent")

research_agent = graph.compile()

result = research_agent.invoke(
    {"messages": [("user", "What is LangGraph's recursion_limit and why does it matter?")]},
    {"recursion_limit": 10}
)
for m in result["messages"]:
    print(type(m).__name__, "|", getattr(m, "content", m))