Ask about the work
behind the demo.

Before the interview: define what you need.

Write a one-page description of the user, the task, the inputs, and the expected result. Include your current software, any access constraints, and the person who will decide whether the result is useful. If the brief still says “add AI,” ask for help with discovery before asking for a full-build estimate.

Separate must-have capabilities from things the team can learn. A project that needs a useful interface, reliable integrations, and a review queue requires more than prompt writing. Decide which skills already exist in your team and which need to come with the hire.

Explore one relevant project in depth.

Choose a past project close enough to reveal transferable judgment. Ask what the person personally built, what existed before they arrived, and who handled the other parts. A team portfolio is useful context; it does not explain an individual's contribution by itself.

“Who used it, and what did they do before it existed?”

Listen for a concrete workflow and a definition of usefulness. A list of model names does not answer this question.

“Walk me through an input, a result, and a correction.”

Ask to see how the system handled an incomplete or ambiguous case. If real material cannot be shared, a redacted walkthrough or a comparable synthetic example can still explain the decisions.

“What part did you own?”

Clarify design, implementation, evaluation, integration, deployment, and ongoing operation. Ask where someone else made the decisions.

“What changed after people started using it?”

Look for specific observations, revisions, and remaining limitations. Treat performance claims as claims until the measurement and context are clear.

Test judgment about your situation.

Use your own brief to discuss the approach without demanding a complete unpaid design. Ask which assumption they would test first and what would make them recommend a simpler solution. A useful answer should explain the uncertainty, the next piece of evidence, and the cost of being wrong.

Ask how they would create a review set and decide whether a change improved the result. Ask what a user sees when a source is missing or a provider request fails. Discuss where a person should approve the output and what must be logged to investigate a problem.

Use a bounded exercise when it adds evidence.

If an exercise is appropriate, keep it closely related to the role. Agree on the scope, expected time, materials, and compensation for substantive project work. Do not use confidential customer records or expect a production-ready system from a short exercise.

Evaluate the reasoning as well as the result. Ask the person to explain assumptions, identify one failure case, and describe the next improvement. Use the same criteria across candidates. An impressive interface should not hide missing checks; an imperfect prototype can still reveal clear engineering judgment.

For a company engagement, ask who will actually do the work and attend the technical discussion. Confirm how responsibilities and access will change if a team member becomes unavailable.

Agree on the working arrangement.

Before starting, document the first deliverable, the acceptance criteria, the review cadence, and the person who can change scope. Decide where the source code lives, who owns provider accounts, and how the team will demonstrate progress. Confirm access and ownership arrangements in the applicable agreement.

Make the after-launch plan explicit. Who investigates a failed job? Who updates dependencies and checks a model change? What does support include, and what requires new scope? A handover should leave the next operator able to understand and run the system.

For an employee, connect these responsibilities to the role and the team around it. For a freelancer, agree on availability and the handover. For a company, distinguish the initial delivery from an ongoing service arrangement. The right answer depends on what your organization can own.