Answering AI Questions

Inventorying Your AI Practice

To help you build a story catalog prepared to answer questions about AI, review each of the five areas below and take a look at the questions embedded in each section. We also provide a few examples of what we think good looks like to get you thinking.

Work: What you actually build with AI

Interviewers want to see that AI made a concrete difference in what you shipped and are looking for specific outcomes: an example of a feature that was completed faster, a pipeline that eliminated some manual work, or tooling that no one else had time to build. Even stronger are stories where the AI didn't just save time but changed what was possible, like a prototype that got delivered in a day, giving leadership confidence it needed to change direction.

Building code with AI is table stakes at this point. What separates strong candidates is using AI in the parts of the job that are harder to automate: bug investigation, design reviews, backlog grooming, incident postmortems. Better yet, have you thought end-to-end about your team's development process and looked to rebuild parts of it?

Equally important to accomplishing work with AI is showing judgment about where AI does and doesn't fit, since not using AI is also a skill and shows you have a coherent mental model of its capabilities. Ask yourself questions like what did you delegate to AI and why specifically that thing? When did you choose not to use it and why? A strong answer has reasoning like, "I started using AI for X but switched off it when Y happened, because I realized it was [generating plausible-sounding guesses / lacking the codebase context / slower than just knowing the answer]. I finished it manually."

What Good Looks Like

• Migrated 40 deprecated API call sites in 3 days instead of 2 sprints
• Used AI to draft all design docs
• Built a loop to address PR comments and update the PR
• Built internal tooling (admin dashboards, data pipelines) that no one had bandwidth for before
• Created a working prototype in hours that would have taken a week, then used it to get buy-in for the full project
• Using AI as a first pass for bugs but quickly ejecting to manual debugging since AI's visibility into your production system is weak

Trust: How you verify and stay safe

For the foreseeable future, there's a tension that using AI will accelerate long-running tasks, but possibly create subtle, or maybe even not-so-subtle, quality issues. You still have to exercise some kind of judgment about what to verify and how to do that efficiently. Interviewers look for this "Trust" signal, so if you just tell stories about shipping stuff quickly, you'll come across as naive and lacking practical skills, especially in a large codebase where one-shotting solutions is unlikely.

Staying safe with AI has a number of facets:

• Testing for Correctness: AI is good at coding, which is verifiable, and bad at writing, because it's hard to define and test for good writing. If you aren't leveraging this fact to verify coding outputs—like with testing regimes and CI/CD hygiene—your codebase will just get worse if you apply AI.
• Recognizing Domain Mistakes: AI gets tripped up by unique issues in different contexts, in different codebases. We're talking about things like legacy patterns or performance constraints, etc. Interviewers will look for evidence that you understand the pitfalls of deploying AI in the domains where you've tried it. What has the model gotten wrong in your specific context that a senior engineer on your team would have known to avoid?
• Managing What You Share: AI tools running on external APIs create a new category of judgment call that didn't exist before around what is safe to reveal. Customer data, internal business logic, unreleased roadmap details, security-sensitive code all carry risk. Strong candidates have thought through this explicitly and can describe a line they've drawn. Interviewers will listen for whether you've developed a structured approach here or just YOLOing it.

What Good Looks Like

• Set up a sandbox cluster so agents can run with fewer restrictions while keeping prod safe
• Created a pre-commit hook that catches common AI mistakes (hardcoded values, missing error handling, our deprecated patterns)
• Caught the model confidently using an internal API that had been deprecated two years ago, that it had discovered from old context
• Built a verification checklist specific to my codebase's gotchas (lock contention, cache invalidation, rate limits)
• Our team uses a self-hosted model for anything touching sensitive customer data

Iteration: How you make AI better over time

Interviewers want to see that you're improving your day-to-day usage of AI as you collect feedback on its performance on whatever tasks you're using it for. AI tools are infrastructure too and need maintenance and retrospective consideration.

Aim to show that you're paying attention and learning on a regular basis. How has your approach you apply or tools you use changed in the last month? When it generates poor outcomes, do you update the system in some way (skills, CLAUDE.md, etc.)?

What Good Looks Like

• Maintain a 200-line CLAUDE.md that's eliminated whole categories of repeated mistakes
• Built a library of reusable prompts for common tasks (migrations, test generation, code reviews)
• Built a kanban-style board to track parallel agent runs to help complete projects faster

Growth: How you learn and stay current with latest AI best-practices

It's worth calling out that learning to stay current in AI is part of an existing Signal Area we've talked about before, also called Growth, but managers will be honing in specifically on AI learning as that part of our work lives changes so rapidly. Engineers who stay current on what's available and make intentional choices to adopt new approaches will obviously perform better than those stuck in old ways of working. Interviewers are likely to ask explicitly about how you're staying on top of AI, but they might also listen passively in your other AI-related stories for hints of how you're applying new techniques and where you got them from.

What separates a strong Growth answer from a weak one is specificity and evidence of actions you take after learning. You should cite sources and techniques you've tried, like blogs or newsletters, and ideally you have some structured approach to learning, which might involve something like experimenting with new techniques on a regular cadence.

What Good Looks Like

• Regular time carveouts to experiment with new AI techniques on real problems
• Explored loop engineering with specific business processes after reading about it
• Built a personal feed of practitioners I trust and actually experiment with what they suggest

Scaling: How you spread AI best practices outside of yourself

There's a lot of signal for the interviewer in how you've gone beyond using AI yourself to how you've transformed individuals and the organizations around you. This can come in the form of breadth—like you disseminate best practices widely around you—and depth—like you fundamentally changed something about the way your business works.

Scaling impact is naturally something we expect more senior engineers to engage in, but even for junior engineers, there is an expectation that you share your learnings about AI workflows and contribute to shared skills, etc. Deeper transformations might involve building tools or running training sessions.

What have you done to expand AI's usage outside of yourself? How have you made compelling proposals for change? How have you handled both resistance from those with concerns and with a tendency for eager engineers to over-rely on AI outputs?

For senior engineers and higher, the largest impact AI can have on an organization is through structural change to workflows. Have you looked at business problems from beginning to end and rebuilt any processes to be better, faster, or cheaper with AI?

What Good Looks Like

• Created a shared rules repo that 5 engineers now contribute to
• Ran "pairing with AI" sessions for skeptical teammates, helping them set up their own configs
• Ran a team retro specifically on AI usage: what's working, what keeps going wrong, what rules should we codify
• Documented team conventions for what goes to AI vs. stays manual, based on our domain complexity
• Produced a set of case studies to help executives understand realistic expectations of AI-powered velocity

Answering "Values Questions" About AI

Because AI workflows are relatively new to software engineering, we see a lot more general discussion of principles and approaches in interviews vs. strictly telling stories about how you've done similar things in the past. Questions like, "How do you generally approach AI-driven development?" or "How are you thinking about the tradeoffs between the volume of AI code generation and the need for verification?" are common. We've called these "Values Questions" earlier in this guide.

These require some kind of structured opinion and they'll be evaluating your judgement as well as comparing you against the current state of the art inside their company—and potentially their own personal biases, which might be hard to assess.

As you look at the five areas we listed above and think about stories from your career that map there, consider the general principles you applied in each project and jot a few down. Take a look at some examples of how you can present these principles in the following question responses:

Where has AI fit within your workflows and where has it not fit?

"There's a pretty clear distinction between the two in how verifiable the result is. I delegate work where the pattern is clear and I can verify quickly—these are things like task triage and publishing weekly updates on team progress.

But I've stayed hands-on where the cost of mistakes is high or context is hard to convey. Those are things like architecture designs and presentations to executives."

How do you balance speed with verification of AI output?

"We've been steadily pushing the envelope toward a 'lights-out' codebase that has no human review, but that's not possible at least with the tools we've tried so far. So we think a lot about what makes AI-output trustable and came up with: unit tests, e2e tests, and making the harnesses capable of doing UI tests themselves…

We've also split the kind of work we do by potential complexity, similar to how we might have more carefully reviewed certain PRs manually. Security-sensitive code gets line-by-line review regardless of who wrote it, for example."

How do you think about AI adoption?

"We've seen AI as a powerful potential tool but one primarily subservient to business needs. We avoided the tokenmaxxing craze for example, which I think helped our eng department secure additional funding for tokens as we've started to use more and more.

Beyond coding itself, instead of identifying tasks that could be accelerated, though that was tempting, we've spent more time assessing our most time intensive workflows end-to-end to discover how they can be reimagined if we have an AI partner. For example, backlog management, task triage, and reviewing bugbash and QA results was taking a decent amount of time and not very satisfying for engineers. We built a loop to review and take action every day on these inputs, always generating a picture of where we were at the end of each day for anyone to consume. That's eliminated hours of meetings each sprint."