Questions about how you use AI at work

“How do you use AI in your work?” has two weak answers: “I don’t”, with no reason, and “it writes most of my code”, with no checks. Both leave the interviewer nothing to score, because what the question looks for is judgement: what you let the tool do, how you checked it and what you kept away from it.

Below are why employers ask, the shape of a strong answer told on one engineer’s story, the data and licence questions that belong in it, and a checker for your own answer.

Why employers ask how you use AI

Some employers now build AI tools into their own interviews. Canva’s engineering blog says that for its backend, machine-learning and frontend roles, candidates are now expected to work with AI tools in technical interviews, and that engineers are expected “to take full ownership of any code they produce”. A question about how you use AI at work asks for the same judgement, shown in your work history; that link is MySmartCoPilot’s reading, not any employer’s statement.

Do not confuse it with the rules of the interview itself:

Google does not permit AI tools during its interviews, Meta’s guide rules out unauthorised outside assistance, which it says includes AI tools, and Microsoft expects your own skills unless help is explicitly permitted. The rules stage by stage are in the interview-prep lesson on AI.

A strong answer shows the check, not only the tool

A strong answer has six parts, a MySmartCoPilot pattern: the task; the tool and what you let it do; how you verified the output; something it got wrong that your check caught; how you handled data; and the measured effect. Arjun, an invented backend engineer, drafted a migration script with the coding assistant his company had approved:

The check is the centre of the story. Arjun’s three hand-written examples passed; a property testproperty-based test: A test that states a rule the code must always keep and checks it on many generated inputs, instead of on a few examples chosen by hand., one rule checked on hundreds of generated inputs, found periods that ended a day early in leap-year Februaries. Canva asks the same of its candidates: “Can they identify and fix issues in AI-generated code?”

A refusal can be a strong answer too, when it comes with its reason: Leela, in the checker below, keeps the assistant away from payroll rules because a wrong rule pays someone wrongly.

Data, security and licences belong in the answer

An answer about AI at work is incomplete until it says what the tool never saw. The OWASP Gen AI Security Project’s list of risks counts as sensitive anything from personal and financial details and health records to confidential business data, passwords and keys, and legal documents, and calls for guidance on keeping them out. Its supply-chain entry adds that different open-source and proprietary licences impose different legal requirements, which matters when a tool suggests code or a library you did not write.

Three sentences cover most answers, and Arjun’s show how:

Students follow their institution’s rules on AI in coursework, and describe only the uses those rules allowed.

Arjun's mistake reproduced: three examples pass, a property fails Pro: opens with a Pro, Premium or Ultimate pass

When not to use it, the probes and a rubric by level Pro: opens with a Pro, Premium or Ultimate pass

Practise: check your AI-at-work answer

Put your own answer to “How do you use AI at work?” in the checker beside these four, and fix what it marks missing:

// Answers to "How do you use AI at work?", checked for the three things that show judgement: how you verified the
// output, something it got wrong or a limit you set with a reason, and how you handled data. Arjun, Leela and their
// answers are invented. Put your own answers in ANSWERS, one string each, and run it again.

const ANSWERS = [
  {
    name: 'Enthusiasm only',
    text: 'I use AI for everything now. It writes most of my code and has doubled my productivity.',
  },
  {
    name: 'A refusal with no reason',
    text: "I don't use AI tools. I prefer to write everything myself.",
  },
  {
    name: 'Arjun, with evidence',
    text: "I drafted a script to migrate our billing periods to a new table with the coding assistant our company had approved. Before running it, I wrote a property test that checked every period ended where the next one began, and it failed on leap-year Februaries: the draft had given every February 28 days. I fixed it and added a checklist for AI-drafted code to our pull-request template. I gave the assistant only the table's schema and made-up sample rows, never customer data.",
  },
  {
    name: 'Leela, a limit with a reason',
    text: 'For our payroll rules I do not use the assistant, because each rule comes from a contract I can check line by line and a wrong rule pays someone wrongly. I use it for test scaffolding instead, which I review before committing. Our policy allows only the approved assistant, and I never paste salary data into it.',
  },
];

// How you verified: tests (not "test scaffolding", which is something the tool wrote), review, comparison, sources.
const VERIFY = /\b(?:(?:property |unit |integration )?tests?(?! scaffolding)|tested|review(?:ed)?|checked|compared|verified|sources?)\b/i;
// Something it got wrong, caught; or a limit you set, with its reason.
const CAUGHT = /\b(?:caught|failed|wrong|bug|errors?|mistakes?|off by one)\b/i;
const LIMIT = /\b(?:do not|don't|never|would not|won't)\s+use\b[^.]*\bbecause\b/i;
// How you handled data: an approved tool, what stayed out of the prompt.
const DATA = /\b(?:approved|policy|never (?:paste|share|put|gave|give)|made-up|synthetic|redacted|masked|only the (?:schema|structure)|no (?:customer|personal) data)\b/i;

let complete = 0;
for (const a of ANSWERS) {
  const verify = VERIFY.exec(a.text);
  const limit = LIMIT.exec(a.text);
  const caught = CAUGHT.exec(a.text);
  const data = DATA.exec(a.text);
  const found = limit ? `a limit with its reason: "${limit[0].split(/\s+/).slice(0, 3).join(' ')} … because"` : caught ? `something caught: "${caught[0]}"` : null;
  console.log(a.name);
  console.log(verify ? `  ok       how you verified: "${verify[0]}"` : '  missing  how you verified: the tests, the review or the source you checked it against');
  console.log(found ? `  ok       ${found}` : '  missing  what it got wrong, or a limit you set: an error your check caught, or where you do not use it and why');
  console.log(data ? `  ok       how you handled data: "${data[0]}"` : '  missing  how you handled data: an approved tool, and what you kept out of the prompt');
  console.log('');
  if (verify && found && data) complete++;
}
console.log(`${complete} of ${ANSWERS.length} answers show all three.`);

Enthusiasm only
  missing  how you verified: the tests, the review or the source you checked it against
  missing  what it got wrong, or a limit you set: an error your check caught, or where you do not use it and why
  missing  how you handled data: an approved tool, and what you kept out of the prompt

A refusal with no reason
  missing  how you verified: the tests, the review or the source you checked it against
  missing  what it got wrong, or a limit you set: an error your check caught, or where you do not use it and why
  missing  how you handled data: an approved tool, and what you kept out of the prompt

Arjun, with evidence
  ok       how you verified: "property test"
  ok       something caught: "failed"
  ok       how you handled data: "approved"

Leela, a limit with a reason
  ok       how you verified: "review"
  ok       a limit with its reason: "do not use … because"
  ok       how you handled data: "policy"

2 of 4 answers show all three.

The first two fail on all three, for opposite reasons: one trusts the tool completely, the other refuses it without a reason.

Interview questions

The first question is a warm-up, answered below it. Answer the other three from your own work, out loud, and read each first step only afterwards.

Key takeaways

• Employers ask how you use AI at work to see judgement; the rules for AI during an interview are a separate question.
• A strong answer has six parts: the task, the tool and its job, how you verified, what it got wrong, what it never saw and the effect.
• A refusal is a strong answer only with its reason, and enthusiasm without a check is a weak one.
• Say which approved tool you used, what you kept out of prompts and how you handled the licences of suggested code.