AI Portfolio Interviews: Explain a Demo That Never Shipped

Your AI demo works, but it never reached production. The strongest portfolio answer separates what you built from what you proved. GitHub’s responsible-use documentation emphasizes reviewing generated work. Our focus here is a specific presentation problem: how to discuss an unfinished or blocked project without turning a prototype into a fictional launch.

Create a contribution map

For each meaningful feature, record the problem, your design choice, AI assistance, human edits, and verification. Link the choice to a diff, issue, test, or screenshot. Keep secrets and customer data redacted.

Explain a rejected suggestion

Choose one plausible proposal you did not ship. State the requirement it violated, the smallest check you ran, and the safer replacement. This is often more persuasive than claiming every generated line was correct.

Make the demo reproducible

Provide setup assumptions, a small test path, and known limitations. If the project depends on a changing model, say which behavior is model-dependent. Reproducibility is a practical signal of ownership.

Worked example: a document assistant blocked before launch

Consider a fictional prototype that answers questions over an internal handbook. The developer built ingestion, retrieval, and a response screen with AI assistance. The demo answered selected examples, but the team stopped the launch because document access controls were not connected to retrieval.

The weak story is “I built an enterprise AI knowledge platform.” A stronger one is “I built and tested a handbook prototype; it did not launch because the prototype could retrieve documents across access boundaries.” The second statement creates room to discuss a real engineering decision without implying production traffic or customer adoption.

Make the unfinished boundary inspectable

Show a sanitized fixture with two users who can access different documents. Demonstrate the prohibited cross-user result, then describe the missing control and where it belongs. If you implemented a fix, show its test. If you only designed it, label it as a proposal. A plan is valuable evidence of reasoning, but it is not proof of working enforcement.

Separate the roles of model output and human work. Perhaps AI drafted the parser while you designed the fixture, identified the access leak, and recommended stopping the launch. Do not inflate that into having written every line manually, or minimize it as merely using a tool.

Handle the follow-up: “What impact can you claim?”

Claim only outcomes you observed. You may have produced a reproducible prototype, found a release-blocking defect, or clarified the next implementation boundary. You cannot claim cost savings at scale, adoption, or production reliability from selected demo questions.

Keep measurements named precisely: local response time on a fixed fixture, answers accepted by two reviewers, or a count of replay cases. Those labels explain the evidence rather than borrowing the language of an operational service. If you have no measured improvement, describe the decision the project enabled.

A useful ninety-second outline is problem, scope, personal contribution, one verified result, why it stopped, and the next acceptance condition. For this example, launch requires document-level access to be enforced before retrieval results reach the model, with negative tests as well as positive ones.

End by showing what you learned that transfers to the new role. “I learned to place access control before answer generation” is defensible. “I proved AI can replace our support team” is not. A small unfinished project with an honest boundary can support a better technical conversation than a grand story that falls apart on the first request for evidence.

FAQ

Should I hide that AI helped?

Do not misrepresent your process. Follow the employer’s disclosure policy and focus on your decisions and verification.

What artifacts are most useful?

A small contribution map, key diff, focused tests, one trade-off record, and a limitation you can explain.

What if the project is private?

Use a redacted architecture sketch, synthetic data, and a narrated verification path without exposing confidential code.

Next Steps

Continue with the complete AI-assisted portfolio evidence guide. For rehearsal, organize your own examples in Interview AiBox materials; this does not automatically validate the claims in your project.

• Feature overview
• Product roadmap
• Current release notes
• Download Interview AiBox