AI agent interview questions and answers

Every command gets a timeout that kills its whole process group, and an output cap. It runs with a minimal environment, so no keys leak in, starting in the repository folder. Each session runs in its own disposable container or microVM as an unprivileged user, with only the repository mounted. The network is off except an allowlist for the package registry. Risky commands, like pushes, need the user's approval, and the work is checkpointed in git.

The denial, with the person's feedback, tells the model what not to do and often what to do instead, like using the staging database. Sent as a tool_result with is_error, it also keeps the transcript valid, since every tool_use needs a result. The agent can then adjust and carry on rather than failing the task or trying the same call again.

Who made it and whether we can review the code, since it runs with our access. Then what it can do: sending email means it can act on our behalf, so I'd want approval prompts on, a scoped account, or a read-only version. And I'd remember that its tool descriptions go into the model's context, so a malicious server could plant instructions.

Dedicated tools let the harness enforce rules a shell can't easily: keep paths inside the workspace, cap output, refuse to edit files the agent hasn't read or that changed, and give clear errors. They also make permissions finer: reading can be allowed freely while edits show the user a clean diff to approve.

Prompt caching reuses an unchanged prefix of the request, so editing an early message makes every later call pay full price and run slower. Replies from models that think also contain signed reasoning blocks tied to the turns before them, and editing those turns can invalidate them. To shrink context, use the deliberate tools, such as clearing old tool results or compaction.

Block it. The hook exists to prevent damage, and a crash means the check didn't happen, so allowing the write would turn the guard off exactly in the unusual cases it's meant to catch. The harness should log the failure and tell the person, so the hook gets fixed. For hooks that only add convenience, like a formatter, carrying on after a crash is fine.

"Summarize this work so another engineer could continue it. Include: the original task in full; decisions made and why; every file created or changed; the current state, such as which tests pass and which fail; errors met and how they were fixed; open questions; and the next steps. Be concise and factual."

Keep a feature list with a passing flag for each item, a progress file each session appends to, and a git commit for each finished piece. Each session starts by reading the progress file, the git log and the feature list. It picks one unfinished item, builds and tests it, commits, then updates the notes and stops with everything working. A project instructions file holds the build and test commands, so no session has to rediscover them.

Tell it the session resumed after a break and that files, branches or running services may have changed, so it should read files again and check the state before editing. Better still, include what changed, such as git status. Its transcript describes yesterday's world, and edits based on stale reads go wrong.

1) Setup: a sales table with 100 known rows. Instruction: "What was total revenue in March?" Grader: the answer contains the right number, within one cent. 2) Same setup plus a customers table. Instruction: "Which three customers spent most this year?" Grader: the three names match, in order. 3) Instruction: "How many orders came from Norway?" There are none. Grader: the answer says zero and doesn't invent rows. In every task the tables are protected, so any write fails the trial.

Pull traces for those runs and look for a shared pattern, such as the same tool failing with the same error over and over. Check the versions on the traces against the deploy log to see what changed: a new prompt, a tool, the model, or an outside API. Reproduce it with an eval task. Then fix the cause, perhaps a tool error that doesn't say how to recover, roll back if needed, and add loop detection plus an alert on this rate.

Every connected tool's definition goes into the model's context on every turn, so eight servers can mean a hundred schemas: more tokens to pay for and process, and too many similar options for the model to pick well. The host should let users switch servers and tools on per task, load full tool definitions only when a search finds them relevant, and keep the tool list stable so prompt caching covers it.

First, an internal allowlist of reviewed servers at pinned versions, so nobody installs a typosquat or a compromised release. Second, the host pins each server's tool definitions at approval and asks again whenever they change, which catches rug pulls, and it shows and scans descriptions for hidden instructions. Third, approvals are required for any tool that writes or sends data outside, and each server gets its own narrowly scoped credentials, so a poisoned server or an injected email can't quietly exfiltrate data.

Return the top ten matches by default, with a cursor for more, and only the fields an agent needs to decide: id, name, price and a one-line summary. Full records come from a separate get_product(id) call, or a detail='full' option. That keeps each result small, so the agent has room to think, and the ids make follow-up calls easy.