1. Start from the problem, not the solution
Open with what someone could not do. Who was affected, how often, and what made the situation costly or risky? Without that framing, your interviewer can judge neither the difficulty of the project nor the relevance of your decisions. One sentence is usually enough: “Support teams kept reopening cases that had already been handled, because nothing let them retrieve a history spread across three systems.”
Then say who asked for it and how success was defined at the outset. Many AI projects fail precisely because that point stays implicit; showing that you made it explicit is already a seniority signal.
2. Name the real constraints
Constraints are what turn an exercise into a project. They explain why the obvious solution was not workable, and therefore why your choices are worth hearing.
- Data: availability, quality, usage rights, confidentiality, volume, freshness.
- Latency: the response time acceptable for real usage, not for the demo.
- Cost: budget per request or per month, and who carries it.
- Quality: the tolerable error level, and what happens when the system is wrong.
- Organisation: available team, in-house skills, ability to maintain the system after you leave.
- Compliance: regulated sector, traceability, hosting, personal data.
3. Explain the choices, don't list them
This is where most candidates slip into stack recitation. The rule is simple: every technology you mention should be immediately followed by the reason it was chosen in that specific context. “We used a vector database” teaches nothing; “the documents were updated daily and retraining was out of the question, so we went for retrieval rather than fine-tuning” shows your reasoning.
Stack version
“We built a RAG system with Python, LangChain, a vector database and a proprietary model for generation, deployed on Kubernetes with a batch ingestion pipeline and monitoring.”
Decisions version
“The documents were revised weekly, with competing versions of the same text. Fine-tuning was ruled out: the corpus moved too fast. So we went for retrieval, investing first in chunking and version metadata, because that is where the inconsistent answers came from. For generation we took the smallest model that met our quality threshold, with a reranking step: the cost per request had to stay compatible with a hundred people using it daily.”
Both versions describe the same project. The second lets your interviewer assess reasoning; the first only lets them tick keywords.
4. Own the trade-offs
A project with no trade-off sounds like a classroom exercise. Mention at least one option you seriously considered and dropped, and say why: deadline, cost, a skill the team did not have, a dependency judged too risky. Also say what you accepted to degrade — functional coverage, latency, completeness — and in exchange for what.
Finally, separate what you decided yourself from what the team decided or the context imposed. That honesty never weakens an application: it is verifiable in one follow-up question, and so is its absence.
5. Show how you evaluated
Evaluation is what most clearly separates a prototype from a system a team can run, and it is often the weakest part of a presentation. Expect precise questions.
- Who defined what a good answer was, and on which sample?
- How did you know a change improved the system rather than moving the problem?
- Did you have a stable evaluation set, or did you judge case by case?
- How did you detect regressions after changing model, prompt or index?
- What did you do with ambiguous cases, the ones a human would hesitate on?
If the project had no evaluation setup, say so, explain how you worked without one, and what you would do differently today. That is more credible than an evaluation reconstructed after the fact.
6. Tell the production story
Many AI projects never left the demo stage, and technical teams know it. If yours reached production, that is a real asset: describe the rollout, the monitoring you put in place, what broke and what you learned. If it stopped earlier, say so plainly and explain why — a clear-eyed stop tells very well.
- What was monitored once live, and by whom.
- Expected behaviour on failure: fallback, message, escalation to a human.
- Guardrails: filtering, usage limits, a deliberately narrow scope.
- What the system could not do, and how that limit was handled on the product side.
7. Close on impact, with no invented numbers
End with what changed for the people involved. If you have real, shareable figures, quote them along with how they were measured. Otherwise describe the nature of the result: a usage that became daily, a task that disappeared, a decision taken earlier, a scope taken over by the internal team. An approximate number you cannot defend costs more than an honest qualitative description.
One last useful reflex: close by connecting the project to the company's own need. “What interests me here is that you are exactly where we were: the prototype works, and the question becomes reliability and cost.” That sentence turns a story into an application.
Before you present your project
Seven points, one per step. Any point you cannot cover is the one to prepare first.
- I can state the problem in one sentence, from the point of view of whoever suffered it.
- I name at least two real constraints that shaped the solution.
- Every technology I mention is justified by a contextual reason.
- I can name one option I dropped and explain why.
- I can say how quality was evaluated, and by whom.
- I can describe the real status: in production, stopped, or still a prototype.
- I describe impact without a number I could not defend.
Key takeaways
- The structure: problem → constraints → choices → trade-offs → evaluation → production → impact.
- A technology only earns its place in the story if the decision behind it is explicit.
- Rejected options demonstrate level better than shipped features.
- Evaluation is the most discriminating point, and the most often skipped.
- An honest qualitative result beats an unverifiable figure.
- AI Engineering
- Evaluation
- Cloud & production