Two things changed what a coding interview looks like, and both landed recently enough that advice from even eighteen months ago now points the wrong way. Agents stopped being autocomplete and started running multi-step loops against your repo, which turned "can you write this function" into a question a model answers in seconds. And enough teams have now shipped agent-written code to production to know exactly which failures repeat, and those repeats are what an interviewer probes to find out whether your experience is real.
Preparing for an AI coding interview in 2026 therefore has little to do with collecting prompting tricks. Five areas carry almost all of the signal:
- The agent loop - how it works, and when an agent is the wrong tool
- Context engineering - what goes in the window, and what quietly ruins it
- Tools, MCP and skills - how an agent reaches the outside world
- Reviewing what the agent wrote - the area that decides most loops
- Shipping it - CI/CD, evaluation, observability, security
Each one below sets out what gets asked and what a strong answer contains. None of it is worth reading in order, though, so begin by locating your own gaps.
Start here: a 6-question self-check
Six questions drawn from squizzu's bank, one for each area below and a second on shipping. Commit to an answer and the explanation opens, followed by a longer breakdown. Nothing to sign up for. Read the result as a routing table rather than a grade, since a miss is simply the section that deserves your slow attention.
The two that catch experienced developers most often are the ones where the correct answer is a refusal. Knowing when not to hand a task to an agent, and knowing that more context makes results worse rather than better, are both counterintuitive if your experience comes from demos, where every task is agent-shaped and every repo is small. Whatever you missed, start there.
What an AI coding interview actually tests
The format varies, but the intent is consistent across the companies now hiring for agentic coding. Three rounds show up repeatedly.
The assisted task. You are given a problem and an agent, and asked to work as you normally would while narrating your decisions. Nobody is counting your keystrokes. They are watching whether you scope the task before delegating it, whether you read what came back, and whether you can explain the result once it works.
The adversarial review. You are handed a diff an agent produced and asked what is wrong with it. Usually something is, and usually it compiles and passes the tests that came with it. This is the round with the widest spread between candidates.
The design conversation. Where does an agent belong in your pipeline, what happens when it fails, and how would you know that it did? This is where evaluation and observability come up, and where people who have only used agents locally tend to run out of road quickly.
The common thread is that all three test judgement rather than recall. A model can enumerate the options for you. Choosing among them, in a specific codebase, under a specific constraint, is still the part that gets paid for.
Area 1: The agent loop, and when not to use it
Start with the mechanism, because most weak answers here are vague about what an agent actually is.
An agent is a model running in a loop, equipped with tools and a stopping condition. It receives a goal, decides on an action, calls a tool, observes the result, and decides again, until it judges the goal met or hits a limit. That last clause carries more weight than it appears to: the model decides when to stop, which is the property that separates an agent from a workflow.
That distinction is worth being able to state cleanly. In a workflow, the code paths are fixed in advance and the model fills in steps. In an agent, the model chooses the path. Workflows are predictable, cheap, and easy to debug. Agents handle tasks you cannot enumerate ahead of time, and pay for it in cost, latency, and variance.
The reasoning patterns layered on top are variations on the same loop. ReAct interleaves reasoning with tool calls so the model can react to what it finds. Plan-and-execute produces a plan up front and then works it, which is cheaper but brittle when the plan meets a surprise. Reflection feeds the model its own output for critique before it commits. Subagents hand a scoped piece of work to a fresh context and return only the result, which is as much a context strategy as an architectural one.
Now the part interviewers actually probe, because it is where enthusiasm outruns experience.
When is an agent the wrong tool? When the task is deterministic and you can write the code, because a loop that costs dollars and sometimes fails is a bad substitute for a function that costs nothing and never does. When the task is a single transformation with no branching, since that is one model call, not a loop. When you cannot verify the output cheaply, because an agent that produces unverifiable work at scale produces liability at scale. And when the failure mode is expensive and silent, which is the case for most data migrations.
Three failure modes are worth naming, because a good answer names them:
- Non-termination. The loop keeps finding one more thing to check. Every serious harness caps turns, tokens, and wall-clock time for this reason.
- Compounding error. A wrong assumption at step two is not re-examined at step nine, it is built on. Long agent runs fail this way far more often than they fail loudly.
- Cost blowup. Each turn resends accumulated context, so token spend grows superlinearly with turns rather than linearly.
Area 2: Context engineering
The term replaced prompt engineering for a concrete reason. In an agentic system the prompt you write is a small fraction of what the model sees. The window also holds system instructions, tool definitions, retrieved files, prior turns, and every tool result so far, and all of it competes for the same finite budget.
So the operative skill is curation. The instinct to add more context is the single most common mistake, and it is worth understanding why it backfires rather than just accepting the rule.
Long contexts degrade in specific, measurable ways. Models retrieve less reliably from the middle of a long window than from either end, so burying the relevant file among forty irrelevant ones makes it likelier to be ignored, not likelier to be used. Irrelevant material also actively distracts, pulling the model toward whatever it saw rather than the task. And a wrong fact that enters the context early tends to persist, since later turns treat it as established.
The techniques that follow from this are the substance of a strong answer:
- Retrieve, do not stuff. Pull the files that matter at the moment they matter, rather than pre-loading the repository. For code, a structural map plus targeted reads beats a dump of everything, and it beats it on both cost and accuracy.
- Compact. When a run gets long, summarise the history into a compact state and continue from that. What you keep in the summary is a design decision: decisions and constraints survive, raw tool output usually should not.
- Externalise. Let the agent write notes, plans, or progress to a file it can re-read. A file is unlimited and stable, whereas context is neither.
- Isolate. Hand a noisy subtask to a subagent whose context you throw away, and return only the answer. Reading forty files to find one function should not cost the main loop forty files of context.
The coding-specific version of this comes up constantly: what do you actually put in the window to make a change in a large repository? A strong answer is the interface and the call sites rather than whole files, the tests that constrain the behaviour, and the conventions the codebase follows. A weak answer is the whole directory.
Area 3: Extending the agent: tools, MCP and skills
An agent without tools is a chat window. How it reaches the outside world is therefore a real design surface, and MCP is the vocabulary the industry settled on for talking about it.
MCP, the Model Context Protocol, is an open standard for connecting models to external tools and data. It defines a client-server interface: a server exposes capabilities, and any compatible client can consume them. The point is combinatorial. A tool written once works with every client that speaks the protocol, instead of being reimplemented for each vendor's assistant.
For an interview, the architecture matters more than the wire format. Servers expose tools the model can call, resources it can read, and prompts it can be given. Clients live inside the assistant and manage the connections. Knowing that shape, and being able to reason about where the trust boundary sits, is worth more than reciting message types.
Tool design is where practical experience shows, and the counterintuitive part is that a tool's description is as much of its interface as its signature. The model selects tools by reading them. A vague description produces a tool that is never called or called wrongly, and no amount of correct implementation fixes that. Two further points that separate people who have built tools from people who have used them: errors should be actionable, so a message the model can respond to beats a stack trace, and tool count should stay small, because selection accuracy falls as the list grows.
Skills are the lighter-weight sibling: packaged instructions and resources the agent loads only when the task calls for them. The idea is progressive disclosure, keeping the window clean until the moment a capability is relevant, which makes this an area 2 technique wearing an area 3 hat.
Then the part that belongs in every answer about tools:
Tool output is untrusted input. A model cannot reliably distinguish data it fetched from instructions it was given, so text arriving from a web page, an issue tracker, or a file in someone else's repository can carry instructions that the model may follow.
This is prompt injection, and in agentic systems it is not a theoretical concern, because the agent holds real permissions. The mitigations are the ordinary ones from security engineering rather than anything AI-specific: least privilege on what the agent can touch, human confirmation on irreversible actions, and treating an MCP server you install as code you are running rather than a plugin you are enabling.
Area 4: Reviewing what the agent wrote
This is the area that decides most loops, and the one candidates most often underprepare, because it cannot be studied without having been burned.
Start with the discipline. Read the diff, not the summary. The explanation an agent writes is generated separately from the code and is not a description of it, so a confident summary can accompany a change that does something else. Reviewing the prose and skipping the diff is the single most common way agent-written bugs reach main.
Then look for the failures that repeat, because they are strikingly consistent:
- APIs that do not exist. Plausible method names on real libraries, invented parameters on real functions. These surface immediately in typed languages and much later in untyped ones.
- Code that works at ten rows. The N+1 query, the nested loop over two collections, the sort inside a request handler. It compiles, the tests pass on fixtures, and it fails at production scale. Spotting this requires knowing how the database actually behaves, which is why fundamentals keep coming up in a conversation that is supposedly about AI.
- Missing error paths. The happy path is complete and the timeout, the partial write, and the retry are absent.
- Tests that assert nothing. This is the subtle one. Generated tests tend to describe the implementation rather than the behaviour, so they pass whether or not the code is correct, and they lock in the current shape so the next refactor breaks them for no reason.
That last point deserves a concrete technique, because it is the answer interviewers are fishing for. Break the implementation on purpose and confirm the test fails. A test that passes against deliberately broken code is not a test, and this check takes seconds. Coverage will not tell you: a generated suite can cover every line while asserting nothing that matters.
Refactoring with an agent runs on the same principle in reverse. Characterise the current behaviour with tests you trust before you change anything, keep each diff to one concern, and refactor separately from behaviour change. The reason is not process for its own sake. A large mixed diff is exactly the artefact human review is worst at, and agents are very good at producing large mixed diffs.
Area 5: Shipping it
The last area is where local experience stops being enough, and it is the one that separates a candidate who has used agents from one who has run them.
CI/CD and automation. An agent in a pipeline is non-deterministic code with credentials, so the questions are about containment: what can it write to, what needs approval, what happens on a failed run, and can you reproduce the run afterwards. Sandboxing and scoped tokens are the expected answers. "It has my keys" is the wrong one.
Evaluation. You cannot unit-test an agent, because the same input legitimately yields different outputs. What you can do is build an eval set of representative tasks with checkable outcomes and track the pass rate as a distribution over repeated runs. LLM-as-judge is the common shortcut for grading open-ended output, and knowing its biases is part of a complete answer: judges favour longer responses, favour their own family of models, and are sensitive to option order. A judge needs calibrating against human labels before you trust it.
Observability. A single agent run is a tree of model calls and tool calls, so the useful unit is a trace with a span per step rather than a log line. What you want on every run is the token and cost accounting, the tool calls with arguments and results, and enough of the input to reconstruct what the model saw. That last one is what makes a failure debuggable instead of merely visible, and it is also why prompt logging collides with data policy often enough to be worth mentioning.
Security and governance. Beyond injection, the recurring themes are secrets reaching a context window that gets logged, an audit trail for actions taken on a human's behalf, and supply chain risk from third-party servers. A useful framing is that an agent is a new principal in your system: it needs an identity, a permission set, and a log, exactly like a service account.
Team practices. Adoption gets measured badly, and noticing that is a credible thing to say. Suggestion acceptance rate says almost nothing, since accepting more code is not the goal. Delivery metrics like change failure rate and review latency are harder to game, and the honest observation is that agents move effort from writing to reviewing, so a team that adopts them without expanding review capacity has moved its bottleneck rather than removed it.
A 7-day preparation plan
One evening a day. It assumes you can already build something with an agent and need structure rather than a starting point.
- Day 1 - The loop. Write the definition until it is 30 seconds: model, tools, stopping condition, who chooses the path. Then list five tasks from your own work and decide for each whether an agent or a workflow fits, and be ready to defend the ones you assigned to a workflow.
- Day 2 - Context. Take a real change in a large repository and assemble by hand the minimum context needed to make it. Then try it with far too much context and compare the results. The comparison is the story you will tell.
- Day 3 - Build a tool. One small MCP server, two tools, deliberately good descriptions. Then make a description vague on purpose and watch selection degrade. Half a day, and it converts area 3 from something you have read about into something you have done.
- Day 4 - Review day. Have an agent implement three non-trivial things, then review the diffs cold and write down every defect. Break each implementation and check the generated tests catch it. Most will not, and those are your examples.
- Day 5 - Evaluate. Build a ten-task eval set for an agent you actually use, run it three times, and look at the variance. This is the fastest way to internalise why "it worked when I tried it" is not evidence.
- Day 6 - Ship one. Put an agent behind a CI step with a scoped token and a sandbox, then make it fail and observe what you can reconstruct from the trace. Whatever you could not reconstruct is what observability is for.
- Day 7 - Say it out loud. Work back through the areas and deliver each answer to an empty room, capped at two minutes: mechanism, trade-off, failure mode, and something you hit this week. Then write down what you want to ask them. "How do you evaluate agent output today?" will tell you more about a team than anything on their careers page.
How ready are you?
Six questions and a few minutes bought you a rough map at the top of this page. The rest of the bank fills it in at the same resolution.
Work through the agentic coding questions on squizzu. Answer, then find out why you were right, which turns a vague sense of being behind into a list of things with names.
If the role leans toward building LLM systems rather than using them, how to prepare for an AI engineer interview covers RAG, evaluation and production risk from the other side. And if what is really bothering you is whether any of this still pays in three years, will AI replace software engineers? takes that question apart with the hiring numbers.
Area 5 also leans on ground you may already hold: the CI/CD quiz covers the pipeline half of it, and the SQL quiz covers the queries you will be asked to find fault with.