How to explain your AI-assisted work in an interview

Why the explanation deserves its own preparation

Employers have made ownership explicit in their published guidance. Canva’s October 2025 interviewer guide evaluates problem solving, technical ownership, and effective AI collaboration. It also asks candidates to answer an interviewer’s question with their own thinking before consulting AI. Canva’s interviewer guide.

Coinbase’s July 2026 update says behavioral discussions now include concrete examples of everyday AI use. Coinbase’s engineering interview update. These are employer-specific statements, not a universal interview rubric. They do make a useful preparation question concrete: can you explain a piece of work without depending on the assistant that helped produce it?

The method below is nrml’s recommendation for preparing a project discussion. It works with professional, open-source, coursework, or personal projects. The important condition is that the work actually happened and that you can accurately describe your role. You do not need a dramatic failure or a company-wide launch to have a worthwhile engineering decision to discuss.

Choose a change with a decision inside it

Start by listing three changes you remember well. For each, write the user’s problem, one constraint, your contribution, and the available evidence. Favor the one where you can explain why you chose one approach over another. A story about a migration script may contain more inspectable judgment than a broad account of building an entire application.

Narrow the scope until the before-and-after behavior fits in a few sentences. Name the unit of work: one endpoint, a report, a failing test, a review, or a release decision. Explain the surrounding system only far enough to make the constraint understandable. The interviewer can ask for architecture details after the central decision is clear.

Identify collaborators now. Record who defined the requirement, who wrote or generated the first implementation, who reviewed it, and who approved release. Those roles can overlap, but they should not disappear into a convenient “we.” Give yourself credit for the work you did and make the boundaries of that contribution easy to follow.

Reconstruct events before polishing the story

Use artifacts you may legitimately access: your notes, a public pull request, a test result, an issue discussion, or a personal repository. Arrange them in the order they happened. Separate what you knew at the time from what you learned later. This prevents a retrospective explanation from making the original decision sound easier than it was.

For each important claim, add the supporting observation. A regression test can show that a particular input changed behavior. A review comment can explain why a proposed abstraction was removed. A deployment record can establish that a change shipped. None of those alone establishes how much time you saved or how customers experienced the release.

When an artifact is unavailable, narrow the claim to what you remember reliably. You can explain a decision without sharing private code or recreating a confidential document. Keep technical details sufficiently abstract for disclosure, while preserving the actual constraint and reasoning. Do not upload an employer’s material to a preparation tool unless you have permission.

Explain the assistant’s contribution at the right level

Describe the task you gave AI and the context it received. “It generated a first pass at the input parser from the documented format” is more informative than “I used AI throughout.” Then identify your next action: checking a boundary, rejecting a dependency, changing the design, or running a test you had specified independently.

Include a disagreement only if one occurred. You do not need to manufacture a model failure to demonstrate ownership. Accepting a useful suggestion can be a considered decision when you explain what made it suitable and how you checked it. Equally, a rejected suggestion matters because of the requirement it missed, not because rejecting AI is inherently impressive.

You usually do not need to memorize the entire prompt conversation. Preserve enough context to explain the division of work and the reason for the decision. A transcript describes what was said; your interview answer should explain what you concluded and what evidence changed your mind.

Make the result no broader than the measurement

If you claim a time saving, identify the comparison. Did you time the same task with and without assistance, compare similar tasks, or simply feel that drafting was quicker? Those support different conclusions. A faster first draft can coexist with longer review and repair. Describe the portion you measured and avoid assigning a percentage to an unmeasured impression.

For correctness, distinguish a demonstrated case from complete coverage. Name the failure the test exposes and the neighboring behaviors you checked. For performance, give the workload and environment. For adoption, explain whether you observed actual use or merely released the feature. The result should remain understandable if the interviewer asks how you know it happened.

A useful exercise is to underline every outcome word in your draft: improved, reduced, shipped, prevented, accelerated. Next to each, write the observation that supports it. Replace unsupported claims with a narrower description. This often makes the answer more concrete without adding length.

Build a short answer with room for follow-up

Rehearse an opening of about two minutes, then practice expanding one decision in detail. This timing is a preparation suggestion, not an employer requirement. Start with the problem and your responsibility. Spend most of the answer on the decision and its evidence. Finish with the observed result and one limitation that actually mattered.

Use the prompts below as notes about your own project, not as a script to fill with impressive-sounding achievements. If a prompt has no truthful answer, remove it or choose a better example. The point is to make the sequence easy to follow while leaving room for a human conversation.

• What was happening before the change, and who needed it to behave differently?

• Which constraint shaped your choice, and what were you personally responsible for?

• What did the assistant contribute, and what decision did you make about that contribution?

• Which observation supported the result, and what remained uncertain?

• What would you revisit if the workload, requirement, or operating environment changed?

Rehearse questions that interrupt the narrative

Ask a practice partner to stop you at the decision and request the alternative you rejected. Then ask them to change one constraint. Explain whether the same choice still works, which evidence carries over, and what needs to be checked again. You are practicing retrieval and reasoning, so allow yourself to pause rather than forcing a memorized transition.

You can also use an assistant as a practice partner before the interview. Give it a factual outline and ask it to challenge unclear claims one at a time. Answer before requesting feedback. Keep any useful follow-up question, but verify factual suggestions against your own records; a persuasive explanation generated during rehearsal does not make an event real.

Permission during an actual assessment is separate. Anthropic’s published policy encourages AI for preparation but requires take-home assessments and live interviews to be completed without it unless explicitly permitted. It also distinguishes refining real experience from inventing experience. Check the instructions for each employer and stage. Anthropic’s candidate AI guidance.

Questions about preparing an honest project story

What if I have not used AI professionally? Say so. Discuss a real personal or open-source project and identify it accurately. Explain what you learned and what you have not yet tested in a production setting. A small completed change gives you something concrete to discuss.

What if I cannot share the repository? Prepare a verbal explanation of the problem, constraints, decision, and verification that respects the project’s confidentiality. You can disclose the limits of what you can show. Do not replace missing evidence with invented details.

What if the interviewer asks something I cannot remember? Separate memory from inference. Explain what you know and how you would recover the missing detail. Your preparation is complete when you can describe the work accurately, follow the reasoning into a new question, and acknowledge where your evidence stops.