How to answer “How do you use AI in your work?” in a software engineer interview

Listing the tools you use is the weakest answer to this question, because it gives the interviewer nothing to probe. The follow-up that exposes a thin answer is “how did you know it was right?”, and the answer that survives it names a check that did not come from the assistant.

The question has moved out of AI-assisted coding rounds and into ordinary behavioral rounds. A behavioral round is the conversation part of an interview, where the questions are “tell me about a time when…”. Candidates on Hello Interview report it from Reddit (senior, late July 2026), Tesla (senior, early August) and Capital One (senior manager, mid-September). The page says seven reports exist and shows three. A PracHub entry posted September 17, 2026 (company not stated) gives its own list of what a strong answer contains: a concrete task, bounded prompts, independent validation, a failure the AI produced, and decisions the candidate owned. Both sites collect candidate submissions, so they show what candidates say they were asked. They are not company policy.

Some companies do say it themselves. Sonar’s interview guidelines say every interview includes questions about how candidates use AI and “where you’ve learned not to trust it.” Canva’s interviewer guide (October 20, 2025) tells candidates to “take time to review and understand everything that gets generated.”

Why the question has stakes now

On October 26, 2026, 404 Media reported that Proton planned follow-up interviews with staff about how they use AI, which an internal email called “consequential.” The Hacker News thread (111 points, 48 comments) split along a line that shapes how to answer. One commenter, joshstrange, argued that not using LLMs would leave an employee “dragging down the company”. Another, bigstrat2003, replied that the time spent reviewing model output “wipes out any potential productivity gains.” A third, yieldcrv, asked the practical question: “what does a good answer look like”, noting that the employees who gush about the company’s AI tools may be the least proficient.

Proton’s CEO later cancelled the re-interviews (a second thread drew 260 comments). The takeaway for a candidate is not Proton’s policy. An interviewer may hold either position, so an answer that claims AI does everything and one that claims it does nothing both sit on one side of a live disagreement. techinterview.org (published May 6, 2026, updated June 30) makes the same point about answers that say “everything” or “nothing”, and gives the likely follow-up as “Where do you still write everything by hand?” The site offers advice without survey data, so treat it as one coach’s view.

An answer with a stated boundary works with either interviewer. The three parts are one task, a limit on what the assistant did, and a check that did not come from the assistant. The check is the hard part, and a concrete bug shows what one looks like.

A bug that passes the examples in the prompt

The task is merging overlapping time ranges for a booking calendar. The spec says ranges that touch (one ends at 3, the next starts at 3) merge too. The function below is hand-written in the shape a first draft commonly takes. It illustrates a type of failure and is not a measured error rate for any model.

def merge_first_draft(ranges):
    out = []
    for start, end in ranges:
        if out and start < out[-1][1]:
            out[-1][1] = max(out[-1][1], end)
        else:
            out.append([start, end])
    return out

Two inputs break it:

merge_first_draft([(1, 3), (3, 5)])   # [[1, 3], [3, 5]]
merge_first_draft([(4, 6), (1, 5)])   # [[4, 6]]

The first leaves two ranges touching at 3 because the comparison is < and not <=. The second is worse. The input is unsorted, so (1, 5) is compared against (4, 6) and folded in with max, and the start of 1 disappears. The block from 1 to 4 is gone from the calendar.

The fix sorts first and merges on <=:

def merge_fixed(ranges):
    out = []
    for start, end in sorted(ranges):
        if out and start <= out[-1][1]:
            out[-1][1] = max(out[-1][1], end)
        else:
            out.append([start, end])
    return out

Reading the code might catch this, and so might a hand-written test. A check that does not depend on the author’s reasoning is stronger. This one expands every range into the set of integer minutes it covers, then requires two things of the output: it covers the same set, and no two output ranges touch. It is called a brute-force oracle: slow and obviously correct, used to judge the fast version.

import random

def covered(ranges):
    return {m for s, e in ranges for m in range(s, e)}

def is_correct(merge, ranges):
    out = merge([tuple(r) for r in ranges])
    same_cover = covered(out) == covered(ranges)
    ordered = all(a[1] < b[0] for a, b in zip(out, out[1:]))
    return same_cover and ordered

random.seed(0)
cases = []
for _ in range(1000):
    rs = []
    for _ in range(random.randint(1, 5)):
        s = random.randint(0, 10)
        rs.append((s, random.randint(s + 1, 11)))
    cases.append(rs)

for f in (merge_first_draft, merge_fixed):
    print(f.__name__, sum(not is_correct(f, rs) for rs in cases), "failures of 1000")

With merge_first_draft and merge_fixed defined above it (Python 3.12.3), it prints:

merge_first_draft 590 failures of 1000
merge_fixed 0 failures of 1000

The first draft fails on 59% of random inputs. Adding sorted(rs) to the first-draft call (is_correct(merge_first_draft, sorted(rs))) still gives 168 failures in the same 1,000 cases, all from the < comparison. A rate that high means a few hand-written tests with unsorted or touching input would also have caught it. The oracle’s value in an interview is different: it is a check that takes one sentence to describe, and the listener can see it does not trust the generated code.

The answer, spoken

Sample answers are written to be said aloud, so they use “I”.

“I use an assistant for first drafts of small, well-specified functions and for test scaffolding. I don’t use it for data model decisions or anything touching permissions.

Last month I asked it for a function to merge booking ranges. I gave it the input format and two examples. The draft passed both examples, but I didn’t merge it, because the examples were all it had been checked against. I wrote a brute-force version that expands each range into the minutes it covers and compared the two on random inputs. The draft failed more than half the time. It assumed sorted input and used a strict comparison, so touching ranges stayed separate and an unsorted range lost its start. I fixed both, kept the random comparison as a test, and noted in the pull request that the function sorts its own input.

I still write the interface and the expected values in the tests myself, because those encode what the feature is supposed to do.”

The “last month” story is a template. Replace it with something that happened to the candidate, since an interviewer who asks for details will find a story that did not.

The answer contains a task, a boundary (small functions, not data models or permissions), a check (the brute-force comparison) and a failure. The failure is the item PracHub’s list includes and most tool-list answers leave out.

Follow-ups to prepare for

“What would you not let it write?” Pick a real boundary and give the reason. Code where a mistake is hard to see, such as permission checks and money arithmetic, is defensible. techinterview.org sketches a similar split: boilerplate and tests heavily assisted, performance- and security-critical code written by a human.

“Nothing, I review everything” is not a boundary.

“What if you had no time to write the oracle?” Name what gets dropped. Use the assistant only for code an existing test suite can check, and hand-write the rest.

“A teammate merged assistant code you think is wrong. What do you do?” Reproduce the failure, then show it in the pull request. The unsorted input above is more persuasive than “I don’t trust generated code”.

“You rarely use AI.” The reasoning has to hold. techinterview.org suggests the shape “I have used Cursor for X but mostly write by hand because Y”. bigstrat2003’s argument in the Proton thread, that review time cancels the gain, is a reason with a testable claim behind it. “I prefer to type” is not.

What changes with seniority

Hello Interview’s page says improving your own execution is enough for junior candidates, and that staff and management candidates are expected to show “broader judgment around standards, risk, and leverage” across people. For senior roles, add a team standard to the story, for example a rule that assistant-written code in the billing module needs a property test before review. Without one, a senior answer sounds like a junior one.

Find the first failing input

Pick a function worth handing to an assistant, such as merging ranges, parsing durations or deduplicating records. Write the brute-force oracle before reading the generated code, run both on a few hundred random inputs, and write down the first input that fails. That input, with a count attached and a check anyone can rerun, is the story. The failure half of the answer follows the same shape as tell me about a time you failed, and the coding-round side of this topic is in how to prepare for an AI-assisted coding interview.