Somewhere in your loop, often the hiring manager round, sometimes the culture fit, you will be asked how you use AI in your work. It sounds like small talk. It isn't. Employers aren't hunting for AI experts; they're screening for people who are adaptable, honest about limits, and comfortable working with the tools. And the question has wrong answers in both directions.
The two failing answers
The refusenik: "I don't really trust it — I prefer to write everything myself." However principled, in 2026 this reads as inflexibility. Teams have AI in the workflow now, from code assistants to review bots to incident summarizers, and a candidate signaling they'll opt out is signaling friction. Even if your usage is genuinely light, "I don't use it" with no curiosity attached is the worst available answer.
The enthusiast without judgment: "It writes most of my code, huge productivity boost!" delivered with no mention of verification tells the interviewer this person ships whatever the model outputs. They'll probe it immediately: "tell me about a time it was wrong." Enthusiasm with no failure story means you're either not looking or not telling. Both lose.
The answer shape that works
Four elements get graded: real usage, a verification habit, a known failure, and a boundary. In practice:
"I use it daily — drafting tests, first-pass implementations of well-specified functions, summarizing unfamiliar code. Everything goes through the same review as my own work, and honestly it fails often enough to keep that habit firm. It once produced a migration that was subtly wrong about our foreign keys, which review caught. I keep it away from the core domain logic where correctness is everything and context is deep."
Thirty seconds. Adoption, skepticism, a concrete story, and a considered limit. Adjust the specifics to your truth. The structure is what's being graded.
The follow-ups to expect
"How do you verify its output?" Have a real answer: tests, review, running it, comparing against docs. "I can usually tell" is not a verification habit.
"Where would you not use it?" Confidential data, security-sensitive code, anything you couldn't personally defend in review. Naming a boundary shows judgment, not reluctance.
"How has it changed how your team works?" This is a trend probe. They want evidence you think about workflow, not just personal tooling. Code review load shifting, more code needing sharper review, juniors learning differently. Any honest observation works.
For senior candidates: expect the leadership version
At senior and staff level the question mutates into "how do you think about AI tools for a team?" The graded answer covers policy, not preference: review standards that don't care who or what wrote the code, guardrails for sensitive surfaces, and helping people adopt tools without atrophying their judgment. Having one opinion about junior-engineer skill development in an AI-assisted world will serve you in every leadership loop this year.
The question is genuinely easy to score well on. It just can't be improvised, because both failure modes are natural reflexes. Decide your answer before the loop, attach one true story of the tool being wrong, and you'll clear a question that trips a surprising number of strong candidates.