Interview prep ยท questions
Working with AI tools interview questions
6 questions, from core to senior. Say your answer out loud first, then open the model answer and check it against the points a strong answer covers.
How do you use AI tools in your daily work?
Show the model answer
I use AI tools as a fast assistant, and I stay responsible for the result. I start with a plan. I describe the task, point the tool to the relevant files, and ask for an approach before any code. I correct the plan, and then I let the tool generate in small steps, one change at a time. I read every diff as I would read a pull request from a colleague. I run the type checker and the tests after each step. I use it most for repeated code, tests, refactoring that follows a clear pattern, first drafts, and questions about code I do not know. Some things stay my decision: the architecture, what the product should do, security and privacy choices, and what gets merged. If I cannot explain a line, I do not commit it.
A strong answer covers
- Plan first: describe the task and agree on the approach before code
- Small steps, one change at a time, and every diff is read
- The type checker and the tests run after each step
- Real uses named: repeated code, tests, refactoring, code I do not know
- Human decisions: architecture, product behavior, security, what gets merged
Likely follow-up
Give one example where an AI tool cost you time. What do you do differently now?
How do you make sure that code written by an AI tool is correct?
Show the model answer
I check it as I would check code from a developer I do not know yet. First I read the whole diff. I must understand every line, and the change must stay inside what I asked for. Then the tools check it: the type checker, the linter and the existing tests. For new behavior I add tests, and I make sure that each test can fail. A generated test can pass without testing anything. I think about edge cases myself: empty input, errors, slow loading, large data and two actions at the same moment. I look at security: user input, HTML injection, secrets and permission checks. If the code uses an API that I do not know, I open the official documentation. A model can invent a function or use an old version. Last, I run the feature in the browser and try it by hand.
A strong answer covers
- The whole diff is read, and every line can be explained
- Type checker, linter and tests pass; a new test is seen to fail first
- Edge cases checked: empty, error, slow, large data, two actions at once
- Security checked: user input, injection, secrets, permissions
- Unknown APIs are checked in the official documentation, and the feature is run by hand
Likely follow-up
The AI wrote the code and also the tests, and all tests pass. Is that enough?
What makes a good prompt when you ask an AI tool to write code?
Show the model answer
A good prompt gives the tool what a new teammate would need to do the task well. I give context: the goal, the relevant files, the framework and its version, and how the code around the change works. I give constraints: follow the existing patterns, add no new dependency, do not change the public API, and stay inside these files. I give an example when I can, such as a similar component, or an input with the expected output. I state the acceptance criteria, so there is a clear definition of done: which cases must work and which tests must pass. I keep the scope small, one task per prompt, because a large request gives a large diff that is hard to review. For a task that is not simple, I ask for a plan first and code second, so I can correct the direction early.
A strong answer covers
- Context: the goal, the relevant files, the framework and its version
- Constraints: existing patterns, no new dependency, which files may change
- An example: similar code, or an input with the expected output
- Acceptance criteria: the cases and tests that define done
- A small scope, and a plan before code for larger tasks
Likely follow-up
The first result is wrong. Do you improve the prompt or fix the code by hand?
Where do AI coding tools go wrong, and how do you catch it?
Show the model answer
They fail in four typical ways. They invent things: a function, an option or a package that does not exist. They use outdated patterns, because their training data is older than the library version in the project. They give a confident fix that hides the symptom: it catches the error or changes the test, and the cause stays. And they change code outside the request, such as deleting code that looked unused. I catch these with the same habits every time: small diffs that I read fully, the type checker and the tests. I check anything unfamiliar in the official documentation, and I confirm that a new package exists before I install it. To recover, I return to the last good commit and do not put fixes on top of a bad change. Then I try again with a smaller task and more context, or I write that part myself.
A strong answer covers
- Invented functions, options or packages
- Outdated patterns for the library version in the project
- A confident fix that hides the symptom: a caught error or a changed test
- Changes outside the request, such as deleted code
- Recovery: back to the last good commit, then a smaller task with more context
Likely follow-up
The tool gives the same wrong answer three times. What do you do?
What rules would you set for using AI coding tools in a team?
Show the model answer
I would set a few clear rules, written down and agreed by the team. First, data. No secrets, keys or customer data go into a prompt. We use only tools that the company has approved, with settings that fit our privacy needs. Second, accountability. The person who opens the pull request owns the code, whoever or whatever wrote it. Saying that the AI wrote it is not an answer in a review or after an incident. Third, review. AI-written code passes the same review, tests and CI as any other code, and pull requests stay small enough for a person to read. Fourth, licenses. We take care with large generated blocks that may copy public code, and we check each new dependency and its license. Fifth, shared conventions. One instruction file in the repository describes our patterns and commands, so every developer gets consistent results.
A strong answer covers
- No secrets or customer data in prompts; only approved tools and settings
- The author of the pull request is accountable for the code
- The same review, tests and CI as for any code; small pull requests
- Licenses: large generated blocks and new dependencies are checked
- A shared instruction file with the team's conventions
Likely follow-up
A junior developer merges AI code that they do not understand, and it breaks production. What do you change?
How much time do AI tools save you, and how do you know?
Show the model answer
My honest answer is that it depends on the task, and I trust measured results more than my own feeling. The gain is large on repeated code, tests, small scripts, changes that follow a clear pattern, and reading code I do not know. It is small or negative on unclear requirements, hard bugs in complex code, and design decisions. There a wrong suggestion costs time to check and undo. To measure, I would not count lines of code or accepted suggestions, because those reward volume. I would look at team results over several months. That means cycle time from first commit to production, defects and rollbacks, and code rewritten soon after merge. If speed goes up but defects and rework also go up, there is no real gain. Published studies do not agree on the size of the effect, so I do not promise a number.
A strong answer covers
- An honest frame: it depends on the task, and no inflated number
- Where it helps: repeated code, tests, scripts, clear patterns, code I do not know
- Where it does not: unclear requirements, hard bugs, design decisions
- Measured by results: cycle time, defects, rollbacks, rework; not lines of code
- More speed with more defects or rework is not a gain
Likely follow-up
Your manager wants each developer to report the hours saved by AI every week. What do you say?