Previously, in Part 4, you whiteboarded a RAG system and learned to defend every box in the diagram.

Now we reach the topic interviewers love most right now: agents. Agentic coding tools sit on every developer's desktop in 2026, so interviewers have met plenty of candidates who can say the word "agent" — and very few who can explain what actually happens under the hood. That gap is your opportunity. Four questions cover most of this territory.

"What makes something an agent rather than a chatbot?"

Why they ask it: This is a vocabulary check with teeth. The interviewer wants to know whether "agent" means something precise to you or whether it's a buzzword you absorbed from product launches. Your answer signals how carefully you think about the systems you build.

A strong answer: A chatbot is a single request–response: you send a message, the model replies, done. An agent runs a loop: it takes a goal, makes a plan, calls a tool, observes the result, and repeats — adjusting the plan based on what it learned — until the goal is met or it gives up. The loop is the defining feature. "Goal → plan → tool call → observe → repeat" is a phrase worth saying out loud in the interview.

Then add the nuance that separates strong candidates: autonomy is a spectrum, not a switch. At one end, a model suggests a single tool call and waits for a human to approve it. At the other, it runs dozens of steps unsupervised. Most production systems live somewhere in the middle, and choosing the point on that spectrum is an engineering decision. If you want a deeper refresher, our what are AI agents post walks through the loop step by step.

Try it: Pick a task like "find every TODO comment in a repo and open an issue for each one." On paper, write out the loop iterations by hand: which tool gets called, what comes back, and what decision the agent makes next. If you can narrate the loop, you can explain agents.

Follow-ups to expect:

  • "Where does the loop actually live — in the model or in your code?" Hint: your code runs the loop; the model only picks the next action.
  • "How does the agent know when to stop?" Hint: explicit stop conditions — the model declares the goal met, or you hit a step limit.
  • "What's the downside of more autonomy?" Hint: errors compound — a wrong step feeds the next step.

Red flag: Calling anything with an LLM inside it an "agent," or describing an agent as a model that "runs on its own." If your definition has no loop and no answer for who executes the tools, the interviewer hears marketing, not engineering.

"Explain function/tool calling like I'm a backend dev."

Why they ask it: This question separates people who once called an SDK from people who understand the contract. It also probes for the single most important fact about tool calling — and many candidates get it exactly backwards.

A strong answer: Tool calling is a structured API contract. Along with the conversation, you send the model a list of tool definitions — each with a name, a description, and a JSON schema for its parameters. When the model decides a tool would help, it does not run anything. It replies with a structured message that says, in effect, "call this function with these arguments": 

{
  "name": "get_invoice",
  "arguments": { "invoice_id": "INV-2093", "include_line_items": true }
}

Your code validates that request, executes the real function, appends the result to the conversation as a tool-result message, and calls the model again. To a backend dev: the model is a planner that emits requests; you own the dispatcher, the executor, and the loop. The model never runs anything itself — say that sentence and you've shown real understanding. It also explains why standards emerged: instead of every app hand-wiring its own integrations, the Model Context Protocol (MCP) gives tools a standard plug, so any MCP-capable client can discover and call them the same way.

Try it: Build a tool-calling loop with no AI at all. Hardcode the "model's" responses as JSON, then write the dispatcher that validates arguments, runs the function, and appends results. Once the plumbing is clear, swap in a real model.

Follow-ups to expect:

  • "What if the model calls a tool that doesn't exist, or with bad arguments?" Hint: validate against the schema, return the error as the tool result, let it retry.
  • "How does the result get back to the model?" Hint: it's appended to the context — everything is just context.
  • "Why do tool names and descriptions matter so much?" Hint: the model chooses tools by reading them — descriptions are prompt engineering.

Red flag: Saying the model "runs the function" or "has access to the database." The moment your explanation grants the model execution powers it doesn't have, the interviewer hears a future security incident.

"How do you keep an agent from doing something destructive?"

Why they ask it: This is the production-readiness question. Companies shipping agents have learned — sometimes painfully — that safety is an architecture concern, not a prompt concern. They want layers, not vibes.

A strong answer: Defense in depth. First, an allow-list: the agent can only call the tools you expose, so expose the smallest useful set. Second, classify every action as reversible or irreversible, and require human approval for the irreversible ones — sending an email, deleting data, spending money. Third, sandboxes: run tools in containers with scoped credentials, read-only where possible, so even a bad call has a small blast radius. Fourth, budgets — step limits, token and spend caps, timeouts — so a confused agent loops five times, not five thousand. Fifth, audit logs of every tool call and its arguments, because you will need to reconstruct what happened. A memorable summary: design as if you're onboarding a very fast junior engineer — and never hand them root.

Try it: Take any agent idea and list its tools in two columns: reversible and irreversible. Decide exactly where the approval gate goes. This ten-minute exercise is the skeleton of a great interview answer.

Follow-ups to expect:

  • "What about prompt injection?" Hint: tool results and web content are untrusted input — treat instructions found there as data, never as commands.
  • "Doesn't approval-for-everything kill the point of an agent?" Hint: risk-based gating — auto-approve reversible actions, gate irreversible ones.
  • "What exactly would you log?" Hint: every tool call, arguments, results, and the decision context.

Red flag: "We'd prompt it to be careful." Prompts are guidance, not enforcement. Guardrails live in code, permissions, and infrastructure — anything else is hoping out loud.

"When would you NOT build an agent?"

Why they ask it: Enthusiasm is cheap; judgment is hired. This question tests whether you reach for the fashionable tool or the right one.

A strong answer: Skip the agent when you can enumerate the steps in advance. A deterministic workflow — extract, transform, notify — belongs in a plain pipeline: cheaper, faster, testable, and debuggable. Simple question-answering over documents needs plain RAG, not a loop. And always name the costs: every agent step adds latency and tokens, multiplied by however many loop iterations it takes, with errors compounding along the way. A good rule of thumb: reach for an agent only when the path depends on what it discovers along the way. Saying "I'd start with the simplest thing that works and add autonomy when the simple version fails" is the kind of sentence that gets written down in interviewer notes — in a good way.

Try it: Classify these three tasks as pipeline, single LLM call, or agent, and justify each: (1) summarize every support ticket nightly, (2) answer questions about your HR policy docs, (3) investigate why a build broke and propose a fix.

Follow-ups to expect:

  • "Your PM insists on 'an agent.' What do you say?" Hint: bring cost, latency, and reliability numbers — and demo the simpler version.
  • "When would you upgrade a pipeline into an agent?" Hint: when branching and edge cases outgrow what you can hardcode.

Red flag: "Agents are always better because they're more flexible." Flexibility is a cost you pay in money, latency, and unpredictability — a candidate who can't see that isn't ready to own a production system.

Where we go next

Agents and RAG are the shiny parts of the interview — but almost every loop still includes a round of classic ML questions, and they sink more candidates than you'd expect. In Part 6, we cover the ML-basics minimum: exactly what you need to sound fluent, and nothing you don't.