In short
There is no single correct answer to "how do you use AI?", because teams disagree on how much to delegate. What interviewers consistently test is accountability: what you hand to the tool, how you check its output, and where you refuse to use it. Answer with one concrete example, then ask how the team itself works.
"How do you use AI in your work?" has become a standard interview question for engineers, and it is now deciding offers. On 2 October 2026 a software engineer with five years of experience posted on r/cscareerquestions that a final round had gone well technically and still ended in a rejection after the leadership panel asked this question. The thread drew more than 300 upvotes and 180 comments, and the replies are a useful map of what hiring teams want to hear.
Why there is no single right answer
The most repeated point in the thread is that interviewers do not agree with each other. One commenter described a loop where the first interviewer advanced them for a cautious answer and the next rejected them for the same one. Some teams want heavy delegation to agents. Others want AI kept behind human review. A hiring manager who asks the question wrote that "it's about alignment": the answer is judged against how that specific team already works.
So the goal is not to guess the preferred amount of AI use. It is to show judgment that makes sense at either end of that range.
What the question is testing
- Accountability. Do you treat the output as yours? The same hiring manager said they look for an understanding that the developer stays accountable for the work, whatever wrote it.
- Whether you can tell when the output is wrong. Several experienced commenters made the same point: reasoning that looks plausible is not enough, and you need to know how you would have built the thing yourself.
- Process. Tests, review steps, guardrails and the setup around the tool, not the tool's name.
- Fit with the team's working mode. A team that merges agent-written changes all day and a team that reviews every line are hiring for different habits.
A structure that works for either kind of team
- Say what you delegate. Name the kinds of task: scaffolding, test generation, refactors, first drafts of a migration.
- Say how you verify it. Reading the diff, running tests you wrote or reviewed, checking the change against the behaviour you expected.
- Say where you do not use it. Security-sensitive code, an unfamiliar codebase you have not read yet, anything where you could not explain the result.
- Give one real example of catching a mistake. A specific bug the tool introduced and how you found it is stronger evidence than any general claim.
- Ask how the team works. "How does your team review agent-written changes?" turns a guessing game into a conversation, and tells you whether you want the job.
Three answers that raise flags
- "I use AI for everything." Without a verification step it reads as dependence. One commenter who uses a coding agent all day wrote that the tool plus analytical thinking is not enough by itself: you also need to know how you would have written the code without it.
- "I avoid it." At a company that has rebuilt its workflow around agents, this reads as a refusal to do the job as it now exists.
- Describing AI use your previous employer had not approved. One commenter said they would not hire someone who was proud of that. If it happened, do not lead with it.
The interview format is changing too
A week earlier, an interviewer on r/ExperiencedDevs described replacing a live coding round with a different exercise: the candidate reviews an agent-generated pull request that touches critical business logic and contains planted bugs of varying severity. That post reached about 1,500 upvotes and more than 900 comments. The interviewer's surprise was that some candidates no longer read generated code at all, and one commenter replied that this would be an automatic disqualification on their team.
If you are preparing for interviews now, practise reviewing code you did not write: read a generated change, find what is wrong, and explain the fix out loud. Our guides to the AI agent live coding interview and agentic AI interview questions cover the rest of the loop.
What our listings show, and what they cannot
As of 4 October 2026, AgenticCareers.co tracks 988 distinct AI roles. Of those, 166 have "agent" or "agentic" in the title, and AI Agent Engineer is the largest category with 182 roles, 127 of them senior level or above. Only 23 of the 988 are junior or intern roles. These are jobs where you are expected to own an outcome, which is the same thing the interview question probes.
What the listings cannot tell you is which answer a particular interviewer wants. A job posting describes the work, not the team's stance on review. That is the reason to ask.
Frequently asked
What is the best answer to "how do you use AI?" in an interview?
Describe what you delegate to AI tools, how you verify the output, and where you choose not to use them, with one concrete example of catching a mistake. Then ask how the team itself works. Interviewers disagree on how much AI use is ideal, but they consistently look for accountability.
Why do candidates get rejected for their answer about AI use?
Usually for sounding either dependent on the tool or dismissive of it. In a widely discussed October 2026 Reddit thread, commenters pointed to two warning signs: "I use AI for everything" with no verification step, and a flat refusal to use it at a company whose workflow depends on it.
Should I say I use AI for everything?
Not without explaining how you check the result. Heavy use is acceptable to many teams if you can show a review process, tests, and that you remain accountable for what ships.
Are AI engineer interviews changing?
Yes. Some teams are replacing live coding with exercises such as reviewing an agent-generated pull request that contains planted bugs, then driving the fixes. Practising code review of work you did not write is useful preparation.