25 LangChain interview questions

Listen for: A strong answer moves beyond “fix the prompt.” Listen for use of structured output APIs, Pydantic v2 schemas, output parsers where appropriate, model capability checks, LangSmith traces, saved bad examples, retry/fallback behavior, and tests around edge cases. They should mention validating at boundaries before the response reaches application code.

Red flag: They rely only on adding stricter wording to the prompt and do not mention validation or tracing.

Listen for: They should inspect the retriever inputs, query rewriting, chunking, metadata filters, score thresholds, reranking, and prompt context formatting. Good candidates use traces to compare the user question, generated search query, retrieved documents, and final answer. They should separate retrieval failures from generation failures before changing the model.

Red flag: They immediately switch to a larger model without checking retrieval quality.

Listen for: Look for judgment about keeping deterministic business rules, validation, authorization, formatting, and data access in code, while using prompts for language tasks requiring interpretation or generation. They should understand prompt templates as versioned, testable artifacts and avoid hiding application logic inside natural language instructions that are hard to review.

Red flag: They put most business rules in the system prompt because it is faster to change.

Listen for: A strong junior candidate checks environment configuration, auth scopes, input schemas, serialization, network access, and differences in model/tool binding. They should use LangSmith or comparable traces to view tool-call arguments, errors, retries, and final messages. Good answers include adding typed schemas and useful error messages rather than swallowing exceptions.

Red flag: They say they would print the prompt and keep rerunning until it works.

Listen for: Listen for layered tests: unit tests for prompt construction and input validation, mocked model tests for chain behavior, schema validation for responses, regression examples for known cases, and lightweight evaluations for factuality or style. They should avoid brittle exact-string assertions except where the output is intentionally constrained.

Red flag: They only test that the endpoint returns HTTP 200.

Listen for: They should mention environment or secret manager usage, no keys in prompts or traces, per-tenant configuration, least-privilege access, log redaction, and not exposing provider errors directly to users. A good answer recognizes that LangChain integrations may pass metadata and callbacks, so tracing configuration must be reviewed for sensitive data.

Red flag: They store keys in a shared config file or LangSmith trace for convenience.

Listen for: Look for an incremental plan: inventory chains, agents, callbacks, memory, and integrations; add regression tests and traces; replace legacy chains with Runnable/LCEL or LangGraph where stateful; update imports split across core, community, and provider packages; preserve behavior before optimizing; and document changed failure modes.

Red flag: They rewrite everything at once because the new APIs are cleaner.

Listen for: Strong answers distinguish short-term conversation state from durable user memory, mention summarization versus windowing, privacy and retention, tenant isolation, retrieval from prior tickets, and user controls. They should consider LangGraph state/checkpointers for workflows and avoid sending entire histories to the model by default.

Red flag: They append every prior message to the prompt indefinitely.

Listen for: They should identify traces for user input, rewritten query, retriever parameters, retrieved chunks, model calls, tool calls, latency, token usage, errors, and final answer metadata. Good candidates discuss redaction, correlation IDs, LangSmith datasets/evaluations, and dashboards that help separate retrieval, orchestration, provider, and application issues.

Red flag: They log the final prompt and response only.

Listen for: A good answer uses LangGraph for stateful, branching, multi-step workflows: human-in-the-loop review, agent loops, retries, resumability, parallel paths, or long-running tasks. They should keep simple deterministic pipelines in LCEL or plain code. Listen for concern about state schema, checkpoints, idempotency, and operational complexity.

Red flag: They use LangGraph for every workflow because it is the newer abstraction.

Listen for: Listen for tool scoping, explicit tool descriptions, typed arguments, policy checks outside the model, confirmation steps, read-only versus write tools, authorization based on user context, dry-run modes, and audit logs. A strong answer does not rely on the model obeying the system prompt as the only control.

Red flag: They add “never call this tool unless needed” to the prompt and consider it solved.

Listen for: Strong candidates define task-specific datasets, expected behaviors, failure categories, and metrics before changing code. They mention offline evaluation in LangSmith or a similar harness, human review for subjective tasks, golden examples, regression checks, and production monitoring. They should compare changes against a baseline, not judge from a few demos.

Red flag: They test with three handpicked questions and rely on gut feel.

Listen for: Look for retries with jitter, concurrency limits, request queues, caching deterministic or repeated calls, streaming where useful, fallbacks by task, batching embeddings, backpressure to clients, and clear error handling. They should consider provider-specific limits and avoid unbounded parallel Runnables that amplify failures.

Red flag: They only increase retry counts, making the outage worse.

Listen for: A senior answer defines supported packages and versions, reference architectures, approved model providers, tracing defaults, security rules, evaluation requirements, and deployment patterns. They should balance autonomy with guardrails, provide reusable components, and create review criteria for prompts, tools, retrieval, and LangGraph workflows without blocking every experiment.

Red flag: They centralize all LLM work in one team and make product teams submit prompt requests.

Listen for: Listen for idempotency keys, separating decision nodes from effectful nodes, durable records of completed operations, transactional boundaries, replay-safe node design, and checkpoint strategy. Strong candidates understand that graph resume/retry semantics require treating tools like distributed system calls, not just Python functions.

Red flag: They disable retries or checkpointing to avoid duplicates.

Listen for: Strong answers separate model selection, prompt contracts, structured output schemas, capability flags, and provider adapters. They mention testing each provider against the same datasets, handling differences in tool calling and streaming, and routing by task requirements. They avoid assuming all chat models behave identically behind LangChain interfaces.

Red flag: They wrap every provider in one generic interface and ignore capability differences.

Listen for: They should discuss traceability from user input through retrieved data, prompts, model versions, tool calls, policy checks, and final output. Good answers include redacted audit logs, evaluation history, release versioning, incident review, and controls that are enforced in code. They should avoid promising perfect explainability from the model alone.

Red flag: They say the model is a black box, so there is nothing useful to investigate.

Listen for: Look for moving orchestration to background workers, using LangGraph checkpoints, job IDs, resumable state, streaming progress, cancellation, timeout policies, and durable queues. They should preserve simple request-response paths where appropriate, define failure recovery, and consider user experience when workflows need human approval or external tools.

Red flag: They keep the HTTP request open for the entire agent run and raise timeouts.

Listen for: Strong candidates profile each step: retrieval, reranking, model calls, tool latency, serialization, and streaming. They discuss model routing by task, prompt/context trimming, caching, embedding reuse, async execution, parallel retrieval where safe, and evaluation-based trade-offs. They should avoid optimizing token count while damaging answer quality or compliance.

Red flag: They switch all calls to the cheapest model without measuring task impact.

Listen for: Listen for checking authorization, input schema, side effects, idempotency, error handling, prompt/tool description, tests with mocked provider calls, observability, redaction, and evaluation examples. Senior candidates also ask whether an agent is needed, whether the tool should be split, and how misuse will be detected in production.

Red flag: They only run the demo path and approve if the agent calls the tool correctly once.

Listen for: A strong design separates RAG answering from ticket-creation tools, uses metadata-filtered retrieval, structured outputs for confidence and citations, and policy checks before side effects. Listen for LangGraph state, human-in-the-loop nodes, checkpoints, audit logs, tenant isolation, feedback capture, and evaluation datasets built from real support scenarios.

Red flag: They build one free-form agent with access to all tools and documents.

Listen for: Look for file ingestion outside the model, chunking and OCR handling, schema-first extraction with Pydantic v2, page-level citations, validation rules in code, retries for ambiguous sections, and LangGraph for review workflows. Good candidates discuss versioned schemas, redaction, batch processing, and regression tests on representative documents.

Red flag: They paste the whole contract into a prompt and trust the model’s JSON.

Listen for: Strong answers restrict SQL generation with semantic layers, read-only roles, query validation, row limits, sensitive-column policies, and approval paths for expensive queries. They should use tool calling carefully, include query explanations, trace generated SQL, cache common results, and evaluate on business questions with known answers.

Red flag: They give the agent unrestricted warehouse credentials and ask it to be careful.

Listen for: Listen for tenant-scoped configs, secrets, vector indexes, trace access, quotas, versioned artifacts, CI evaluation gates, deployment promotion, rollback, and shared libraries. Good designs include standard callback/redaction behavior, provider routing, compatibility testing for LangChain upgrades, and clear ownership of each workflow in production.

Red flag: They use a single shared vector store, trace project, and service account for all teams.

Listen for: A strong design uses a graph for planning, search, document retrieval, note taking, synthesis, and verification. Listen for source deduplication, citation tracking, freshness checks, rate limiting, prompt-injection defenses for web content, human review options, and evaluation against briefs with known source requirements and factual constraints.

Red flag: They let the model browse and summarize freely without source validation.