AI interview evidence: demonstrate your contribution, verification and results

Career OS™ MOVE · Interview Mastery

How to Demonstrate AI Impact in Your Next Interview

An Eich Dyn Career OS™ practical guide for engineers, researchers, data scientists, developers and technical leaders.

By Dai Jones · Eich Dyn Career Services · Written 25 October 2026

7 min read

“I use ChatGPT” is not an interview answer. The stronger answer is: I identified a problem, used an appropriate AI approach, checked the risks, retained responsibility for the decision and can explain what improved.

Why your AI experience needs evidence

When a technical interviewer asks how you use artificial intelligence, naming ChatGPT, Copilot, Claude or a coding assistant tells them little. They need to know whether your approach changes engineering throughput, research quality, product decisions or the capability of the people around you.

An October 2026 study of hiring and work at Anthropic found that references to candidates’ AI-tool experience increased substantially in its own interviews. Its researchers also reported greater discussion of candidate autonomy and judgement in technical assessments. This is a signal from one AI-intensive US company — not proof that every engineering employer now has the same interview criteria. Preparing an evidence-led answer is sensible wherever AI changes how technical work gets done. Source: Anthropic, How employment is changing at Anthropic.

The question behind the question: Can you use AI to produce a defensible improvement rather than just faster-looking output?

Five things an interviewer needs to hear

The problem and baseline. What was slow, costly, inconsistent, hard to research or difficult to decide? State the previous process, constraints and, where measured, its baseline.
Your contribution. Were you the initiator, builder, evaluator, technical lead or approver? Say which parts you actually did. “The team implemented AI” is not the same as “I defined the use case and validated the pilot”.
What the AI did. Explain the workflow in ordinary professional language. Was it summarising technical literature, helping write code, extracting structured test evidence, assisting users or orchestrating steps through an agent? Name a tool only when its characteristics mattered to the result.
How you checked it. How did you detect hallucinations, omissions, numerical errors, poor references, bias or confidentiality risks? What evidence did you compare against? Which safety, data, model or engineering controls applied? Where was human sign-off essential?
The measurable effect. Give the before and after, the observation period and the net result: hours released, cycle time reduced, defect detection improved, better research coverage, more timely decisions or lower review effort. Be honest about uncertainty and what has not yet been measured.

These points matter more at senior levels, where judgement, governance, resource allocation and adoption across a team become part of the assessment.

Three industry examples you can adapt

The following are illustrative examples, not Eich Dyn client outcomes or verified industry case studies. Any figures you eventually use must come from your own evidence.

Example 1 — Automotive engineer: accelerate test-data triage

Weak: “I used AI to help with vehicle testing.”

Stronger: “I identified that our engineers spent too much time grouping repeat test-track issue descriptions before they could investigate root causes. I piloted an approved AI-assisted classification workflow for non-sensitive issue logs, designed categories with the test team and compared its output with independent engineer reviews. I monitored missed safety-relevant events and false classifications, with engineers retaining the responsibility for diagnosis. We then compared end-to-end triage time and correction effort against the previous process, not simply the first-pass drafting speed.”

Evidence to bring: agreed classification accuracy, missed-critical-issue rate, engineer review hours, turnaround time, traceable test-log references and the go/no-go decision.

Example 2 — Clean-energy researcher: strengthen technical research

Weak: “I asked an AI to summarise battery research.”

Stronger: “To support a thermal-management decision, I used an AI research assistant to organise a first-pass map of published battery degradation studies and competing explanations. I checked the original papers, experimental conditions and source dates, distinguished replicated findings from speculative claims, and recorded conflicts requiring further experiments. I used the evidence map to recommend tests, rather than allowing generated summaries to determine the design.”

Evidence to bring: number and relevance of papers independently checked, source-traceability rate, research hours, gaps found, experiments prioritised and the eventual quality of the decision. A broader search is not automatically better research.

Example 3 — Data scientist or developer: build a controlled AI agent

Weak: “I built an agent that automates data quality.”

Stronger: “I prototyped an agent that monitored schema changes, flagged unusual data-quality patterns, assembled diagnostic evidence and drafted a ticket for the owning team. It could not independently alter production data. I defined test cases for missed and false alerts, set permissions and an escalation path, and measured triage time alongside the review burden. We only expanded the pilot after comparing net value with the existing monitoring process.”

Evidence to bring: precision and recall, false-alert rate, time to detection, human triage time, incident count, audit logs, permissions and deployment approval.

The common principle: Describe the workflow, verification, decision rights and impact. Tools are part of the story, not the headline.

Present AI impact with clear ownership, safeguards and evidence

Your 90-second AI interview answer: P.R.O.V.E.

Use the same P.R.O.V.E. structure as Eich Dyn’s comprehensive AI career evidence guide.

P — Problem and baseline (15 seconds). “Our [process] was taking [time] and creating [risk or bottleneck]. I established a baseline using [method].”

R — Responsibility and reasoning (15 seconds). “I owned [specific contribution] and chose AI because [why it was suitable], rather than [alternative].”

O — Operation and orchestration (20 seconds). “I built or introduced [workflow], using [approved tools or data], with clear boundaries for what the system could and could not do.”

V — Verification and safeguards (20 seconds). “I tested outputs against [independent evidence], measured [error/quality indicator], protected [confidentiality or safety requirement] and retained human approval for [critical decision].”

E — Effect and evidence (20 seconds). “Against [baseline], the process delivered [verified result] across [period]. The net gain included [quality, capacity or value]; what remained uncertain was [limitation].”

Practise this aloud. The best 90-second answer should generate informed follow-up questions. If an interviewer asks “How do you know the result was caused by your intervention?”, be ready to discuss controls, confounding factors and how you measured the outcome.

What if you have not yet delivered a production AI project?

You can still give a credible answer. Explain a limited pilot, what you tested, what was learned and why you did or did not deploy it. If you used AI to improve your personal workflow, describe it accurately as personal productivity — do not claim an organisation-wide improvement.

A senior professional can demonstrate judgement by rejecting an AI use case when its error rate, data exposure, integration overhead or assurance burden outweighs any possible efficiency gain. This aligns with established AI risk-management principles emphasising governance, measurement and ongoing management rather than uncritical automation. Source: NIST AI Risk Management Framework Core.

In defence, clinical products, automotive safety or aviation, never imply that an AI output substitutes for approved engineering verification, clinical judgement, classification controls, cybersecurity reviews or regulatory obligations. Explain the approved environment, authorisation and sign-off.

Your preparation checklist

Before your next technical interview, prepare one strong example you can defend:

Identify a real problem with a clearly described baseline.
State exactly what you did, versus what the team or tool did.
Explain why AI was appropriate and what alternative you considered.
Bring proof: approved metrics, traceable examples, test results or carefully anonymised evidence.
Name your validation approach, confidentiality controls and human decision boundary.
Separate measured outcomes from estimates or pilot hypotheses.
Prepare two follow-up answers: “What failed?” and “What would you do differently?”
Rehearse a 90-second version and a detailed three-minute version.

Do not bring confidential datasets, proprietary prompts, controlled designs, unpublished research or sensitive product information into a public interview. Use approved, anonymised descriptions, ranges where appropriate, and explain the methodology.

The next step

If you are preparing for an external move, build this evidence into [Career OS™ MOVE — Interview Mastery](/guidebook/interviewing). If you are pursuing an internal appointment, use the same evidence to support [Career OS™ PROPEL — Outcomes and Evidence](/guidebook/propel/outcomes-evidence).

For the full sector-by-sector reference, including 36 illustrative examples across data science/AI, clean energy, defence, digital healthcare, automotive and aerospace, read Using AI Is No Longer Enough: Prove the Value You Deliver.

If you need help translating technical work into a convincing interview or promotion narrative, explore Eich Dyn’s interview support or book a Career Diagnosis.

Frequently asked questions

Must I name the AI tools I used?

Only when the tool choice matters to the explanation. Interviewers need to understand the task, your judgement, validation and outcome more than a list of brand names.

Can I discuss a failed AI pilot?

Yes. State the hypothesis, evaluation method, observed failure, risk controls and the decision you made. Do not disguise a failed pilot as a deployed success.

What if I cannot share commercial figures?

Use permissioned ranges, proportions or non-confidential process descriptions. Explain the measurement method and decision impact without revealing restricted material.

Sources and further reading

Anthropic, How employment is changing at Anthropic (16 October 2026) — observational findings about hiring and work inside Anthropic; not a claim about all employers.
US National Institute of Standards and Technology, AI Risk Management Framework Core — governance, risk identification, measurement and responsible management of AI systems.
Eich Dyn: Using AI Is No Longer Enough — full research and six-industry use-case library — detailed evidence, P.R.O.V.E. and 36 clearly labelled illustrative cases.