Tools of the Trade & Interview Prep

You now have the mental models and the measurement discipline. This chapter maps them onto the real tools you'll name in an interview, then rehearses the questions — with the senior answers — that separate someone who has shipped agents from someone who has read about them.

The stack, by concern

Interview simulation — the questions and the senior answers

Q1. "When would you not build an agent?"

Weak answer: "Agents are always better." Senior answer: "Whenever I can write down the steps. If the control flow is fixed — fetch, summarize, route — it's a workflow, and an agent just adds latency, cost, and non-determinism for flexibility I don't need. I reach for an agent only when the steps depend on what the model discovers mid-task." (Ch. 1.)

Q2. "Our agent sometimes runs forever. How do you fix it?"

Senior answer: "Three layers. A hard max_steps cap so it always terminates. Stuck-detection on repeated (tool, args) to bail early with a nudge before the cap. And a per-request token/dollar budget so tail-risk is bounded. Then I log the stop reason — natural/stuck/capped — and watch the capped rate as a health metric." (Ch. 3, 10.)

Q3. "The agent keeps calling the wrong tool. Where do you look first?"

Senior answer: "The tool descriptions, before anything else. Routing is driven almost entirely by the name and description text. I make each say what it does, when to use it, and when not to — I've seen that alone take routing from the low-60s to the mid-90s. If there are hundreds of tools, I stop loading them all and retrieve the relevant few per query." (Ch. 2, 11.)

Q4. "How do you know one agent version is better than another?"

Senior answer: "A fixed task set with checkable outcomes, scored on success rate, steps, and cost — never success alone, because a higher success rate at 4× the steps is often a worse product. Agents are non-deterministic, so I report a rate over the set, and I keep a failure taxonomy to know what to fix. Every change — a prompt, reflection, a new model — is a before/after on that harness." (Ch. 8.)

Q5. "How do you let an agent take real actions safely?"

Senior answer: "Tier tools by reversibility. Read-only and easily-undone actions run automatically; irreversible ones — sending, deleting, payments — pause for a human approval that shows the action in plain terms. That gate is also my backstop against prompt injection: even if a tool result poisons the context into proposing something destructive, it can't execute without a human yes. And mutating tools are idempotent so retries don't double-fire." (Ch. 7, 9.)

Q6. "Multi-agent — when and why?"

Senior answer: "Only for wide, parallel, independent sub-tasks whose value justifies roughly an order-of-magnitude more tokens — deep research, fan-out gathering. Orchestrator–worker with structured handoffs. For sequential or interdependent work I stay single-agent, because I'd pay the token multiple for no parallelism. I start single and graduate only when a real isolation or parallelism need shows up." (Ch. 6.)