How do you use AI in your work?

Question: How do you use AI in your work?

Companies: Anthropic, OpenAI, Cursor, xAI, Amazon, Meta

Problem statement

Describe how AI tools fit into your engineering work: where they help, where they fail, how you verify their output, and how they have changed the way you or your team work.

What the question probes

Every AI company now asks some version of this, usually in the recruiter screen, the hiring-manager round, or as a warm-up in a coding round where AI tools are allowed. It sounds like small talk. It isn't. The interviewer is checking four things:

1. Do you actually use these tools, daily, on real work? People who build AI products and don't use them miss what users feel.
2. Do you know where they fail? The best answer has as much about where AI got it wrong as where it helped.
3. Do you verify? The trait every AI-native team worries about is an engineer who merges code they don't understand.
4. Has it changed how you work, not just how fast? Senior candidates describe a different workflow, not a faster keyboard.

A weak answer is a list of tool names. A strong answer is a description of a workflow with numbers, a failure, and a rule you follow because of that failure.

A structure that works

Answer in about 90 seconds, then let them pull on threads:

1. Where it sits in your week. Two or three concrete uses, ranked by how much they matter.
2. One example with numbers. A task, how long it took before, how long it takes now, and what you did with the time.
3. One failure and the rule it taught you. The bug that slipped through, the confident wrong answer, the security issue.
4. How you verify. Tests, reading every line, running it, asking for sources, a second model as a reviewer.
5. What you think comes next. A view on where the tools are going and what that means for your role.

Prepare your own version. The examples below show the shape; replace them with yours when you remix.

Worked example (L4/L5)

A backend engineer on a payments team:

"I use AI in three places, in order of how much it matters. First, reading unfamiliar code: when I'm dropped into a service I haven't touched, I have an agent walk the call graph and explain the request path, then I verify the claims by setting breakpoints. That took me a day or two per service before and now takes about two hours. Second, tests: I write the cases I care about by hand, then ask for edge cases I missed. It finds one or two real ones per feature, usually around time zones or currency rounding. Third, first drafts of migrations and scripts.

The failure that shaped how I work: an agent wrote a backfill script that looked right, and in review I checked the logic but not the batch boundaries. It processed one batch twice because it used >= on both ends of the window. We caught it in staging because the totals didn't reconcile, but it would have double-credited about 1,200 accounts. Since then my rule is that anything touching money gets an invariant check I write myself (sum before equals sum after), and I never let the tool write the check that validates its own code.

I'd say it's made me about 30% faster on implementation, but the bigger change is that I spend more of my time on reading and reviewing than writing, so I've gotten deliberate about reviewing well."

Worked example (L6)

A staff engineer who leads a platform group:

"For me personally, the biggest change is that I run two or three agents in parallel on well-scoped tasks while I do design work, and I review their pull requests like a teammate's. The scoping is the skill: a task with a clear spec and an existing test suite succeeds most of the time; a vague one wastes more time than it saves. I've started writing short task specs (goal, constraints, files that matter, how to verify) before I hand anything off, and those specs turned out to help human teammates too.

At the team level I measured instead of guessing. Over one quarter we tagged 400 merged pull requests as AI-assisted or not. Assisted PRs merged about 35% faster, but their revert rate was 4% against 2.5% for the rest. Looking at the reverts, most came from changes that crossed service boundaries, where the tool didn't know about a consumer in another repo. So we changed two things: every service's README now lists its consumers, which the agents read, and cross-service changes need a human-written design note. The revert rate came back to about the baseline the next quarter while keeping most of the speed-up.

Where I think this goes: the bottleneck moves to specifying and verifying. The engineers who'll do best are the ones who can say precisely what they want and can tell quickly whether they got it. That's what I'm hiring and mentoring for now."

Why it reads as L6: measured at the team level, found a specific failure mode with data, changed process and documentation rather than banning the tool, and has a view on how the role changes.

Where AI helps and where it doesn't

Have your own version of this table. Interviewers like candidates who can draw the line precisely.

If the company builds the AI

At Anthropic, OpenAI, xAI, Cursor and similar companies, add one more layer: you are also a user giving feedback on the product. Be ready to say:

• One thing the tool you use most does badly, specifically ("it rewrites files it didn't need to touch", "it gives up on long debugging loops"), and how you'd measure that.
• How you'd evaluate whether a new model is better for your kind of work (a fixed set of 20 real tasks from your history, scored on pass rate and review time, not vibes).
• What you think about the limits: privacy of code sent to a model, over-reliance by juniors, the skills you worry about losing.

Be honest about which tools you use, including competitors'. Pretending to use only the interviewer's product is easy to spot and doesn't help.

Red flags

• "I don't really use it." At an AI company this is close to disqualifying unless you have a specific, thought-through reason.
• "I use it for everything." Without a word about verification, it sounds like you merge what you don't understand.
• Tool names instead of workflows. "I use Claude Code and Cursor" says nothing.
• Productivity claims with no evidence. "10× faster" invites "how did you measure that?"
• No failure story. Everyone who uses these tools seriously has one.
• Dismissing juniors or the craft. "Nobody needs to learn X any more" worries interviewers who are building teams.

Follow-ups

• "Tell me about a time AI-generated code caused a problem."
• "How do you review a pull request you know was mostly written by a model?"
• "How would you onboard a new graduate in a team where everyone uses agents?"
• "If our coding round allows AI tools, what should we grade?" (A good answer: problem decomposition, verification, and how you respond when the tool is wrong.)
• "What would make you trust an agent to merge without review?"
• "What's a task you tried to hand to AI and took back?"

Interviewer expectations

Mid-level (L4)

• Uses AI tools daily on real work and can describe two or three concrete uses.
• Has a failure story and a verification habit that came from it.
• Understands every line they ship and says so.

Senior (L5)

• Describes a workflow that changed, with a before/after estimate grounded in real tasks.
• Draws a precise line between work AI does well and work that needs heavy verification, with reasons.
• Has concrete product feedback about the tools they use and could design a small eval to compare models on their own work.

Staff (L6+)

• Measured the effect at team level (speed, quality, reverts) and changed process or documentation based on it.
• Has a view on how roles, hiring and mentoring change, including the risks for junior engineers.
• Talks about the organizational limits: data policy, security review of agent actions, and when an agent can act without a human.