AI Coding & Agentic Development interview questions
AI Coding & Agentic Development questions a AI engineer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
What is the difference between an AI coding assistant and a coding agent, and why does it matter for how you work?
The strongest answer: An assistant suggests code that I apply; an agent works in a loop — reads the repo, edits files, runs commands, reacts to results — so it needs a clear task, limited permissions and review
Why it works: Right — the loop and the ability to act are the difference, and acting is why scope, permissions and review matter more.
- Assistant suggests; agent acts in a loop.
- Give an agent a clear, bounded task.
- Limit what it can touch and run.
- Review what it did, not what it says.
Your coding assistant’s solution imports a library you have never heard of. What do you do before you install it?
The strongest answer: Check the package really exists in the official registry, is the maintained one and has the functions the code calls — models invent plausible names, and an invented name can be registered by an attacker
Why it works: Exactly — hallucinated dependencies are a known failure, and installing an unknown package runs someone else’s code on your machine.
- Verify dependencies outside the model.
- Confirm the package exists and is maintained.
- Check the API matches the installed version.
- Never install to find out.
You are handing a feature to a coding agent. What goes into the task you write for it?
The strongest answer: The goal and why, the files and patterns to follow, what it must not touch, and acceptance criteria it can run — the tests or commands that prove it is done
Why it works: Exactly — an agent with a runnable definition of done can check itself; without one it stops when the code merely looks finished.
- Brief the agent like a new hire.
- State the goal and the constraints.
- Point at files and patterns to follow.
- Give acceptance checks it can run.
You asked an assistant to write unit tests for an existing module. It produced forty tests, all green, and coverage jumped.
What do you check before you trust them?
The strongest answer: That they assert the intended behaviour, not just whatever the code does today — I read the assertions, break the code on purpose to see tests fail, and add the edge cases from the spec
Why it works: Exactly — tests generated from the code tend to lock in its current behaviour, bugs included. A test that cannot fail proves nothing.
- A test that cannot fail proves nothing.
- Read the assertions, not the count.
- Break the code; watch a test fail.
- Add the spec’s edge cases yourself.
A teammate’s coding agent opens one pull request: 2,400 changed lines across 45 files, mixing a rename, a dependency bump and a new feature. CI is green.
You are the reviewer. What do you do?
The strongest answer: Ask for it to be split: the mechanical rename, the dependency bump and the feature as separate small branches, each green alone — a diff nobody can read has not been reviewed, whoever wrote it
Why it works: Exactly — agents make big diffs cheap to produce, not cheap to verify. Small single-purpose branches keep review real and rollback possible.
- Generating is cheap; reviewing is the bottleneck.
- One purpose per branch.
- Mechanical changes separate from behaviour.
- Approve only what you read.
Your team’s coding agent keeps producing working code that ignores the codebase: a second HTTP client, a new date helper that already exists, tests in the wrong framework.
What do you fix?
The strongest answer: The context it works from — a maintained project instructions file with conventions and build and test commands, pointers to exemplar files, and tasks scoped so the relevant code is actually in front of it
Why it works: Right — the agent only knows what it has read. Conventions it cannot see do not exist for it, so write them down and show examples.
- An agent knows only what it has read.
- Write conventions where the agent loads them.
- Point at exemplar files.
- Scope tasks to the relevant code.
A production incident is traced to agent-written code. The author says the agent wrote it; the reviewer says it looked fine and CI passed. Neither can explain what the function does.
You lead the team. What do you change?
The strongest answer: Ownership, not the tool: whoever opens the pull request answers for every line as their own, review holds the same bar whatever wrote it, and we fix the pressure that made unread merges normal
Why it works: Exactly — the tool has no accountability, so it cannot share any. The incident is that two people signed for code neither understood.
- The person who merges owns the code.
- Author must be able to explain it.
- Same review bar for any source.
- Fix the pressure behind rubber-stamping.
You want to use coding agents to move about 300 modules off a deprecated internal API. How do you run that so it is safe?
The strongest answer: Pin current behaviour with tests, migrate a few modules by hand to get a written recipe, then have agents apply it in small independent batches — each through CI and review — with odd cases listed for humans
Why it works: Exactly — decompose, make the recipe explicit, and make every batch verifiable and revertible. The agents supply speed; the structure supplies safety.
- Decompose; make each step verifiable.
- Pin behaviour with tests first.
- Do a few by hand; write the recipe.
- Small batches through CI and review.