Demo your GenAI project in an interview¶

Beginner · 15 min · no code required

"Walk me through a project you've built" is in almost every GenAI interview. It's the one question you can fully prepare for, and it decides more interviews than any coding puzzle. The goal isn't to show everything you built. It's to show how you think: the problem, the decisions, the trade-offs, and how you know it works.

1. The 5-minute structure¶

Minute	Part	What to say
0:00-0:30	Problem	Who has the problem and why it matters. One or two sentences
0:30-2:00	Demo	One realistic question, end to end. Point out what's happening (citations, streaming, refusal)
2:00-3:00	Architecture	One diagram. Walk the request path: UI → API → retrieval → LLM → answer
3:00-4:15	Two key decisions	What you chose, what you compared it against, and why. With numbers if you have them
4:15-5:00	Results and next steps	How you measured it, what's still weak, what you'd do next

Example opening: "Insurance policies are 80-page PDFs, and agents spend minutes finding one clause. I built PolicyPal, a RAG assistant that answers questions with the exact page it came from. Let me show you."

Stop at five minutes and let them ask. Interviewers want a conversation, not a lecture, and their questions tell you what they care about.

2. Talk about decisions, not features¶

Weak: "I used LangChain, Pinecone and GPT-4o." That's a shopping list.

Strong: "Plain vector search missed questions with exact terms like policy numbers, so I added BM25 and merged the results with reciprocal rank fusion. On my 60-question eval set that raised correctness from 0.71 to 0.80, and a reranker took it to 0.87 for about 300 ms more latency, which was fine for this use case."

The strong version has the problem, the alternative, the choice, the evidence and the trade-off. Prepare two or three of these stories in advance. Good candidates:

Chunking strategy and why
Retrieval (vector vs hybrid, reranking, top-k)
Model choice (quality vs cost vs latency)
How you handle "I don't know" and hallucinations
How you evaluated it

3. A demo that can't fail¶

Live demos fail at the worst moment: Wi-Fi, a sleeping free-tier server, an expired key, a model having an off day.

Wake the app up 10 minutes before (free tiers sleep) and test the exact question you'll ask.
Have 2-3 prepared questions that show your best features. Type them from a notes file; don't improvise.
Record a backup video (60-90 seconds) and have it open in a tab. If anything breaks: "Let me show you the recording while it reconnects." Nobody minds; panicking is what hurts.
Close other tabs and notifications, increase the font size, and use a clean browser profile.
Know where the code for each part lives, in case they say "show me the retrieval code".

Show a failure on purpose¶

Ask one question the documents can't answer, and show your app saying so instead of making something up. Then show one case where it gets something wrong and explain why. This is the most convincing thing you can do: it shows you understand the system's limits and you've tested it honestly.

4. Questions you'll get, and how to answer¶

How do you know it works? How did you evaluate it?

Describe your eval set (how many questions, how you wrote them, from real documents), the metrics (answer correctness, faithfulness, retrieval hit rate) and the tool (RAGAS, LLM-as-judge with spot checks). Give before/after numbers for a change you made. If you didn't evaluate, say what you'd do, and then go build a 20-question eval before your next interview.

How do you handle hallucinations?

Instruct the model to answer only from the context and to say when it can't; require citations; check that cited chunks support the answer; show sources in the UI; measure faithfulness in evals; and tune retrieval, because most "hallucinations" in RAG are really retrieval misses.

What does it cost per query, and how would you reduce it?

Know your numbers: average input and output tokens and the price per query (see Count tokens and estimate cost). Levers: fewer and better chunks, prompt caching, a smaller model for easy questions, capping output length, caching frequent answers.

How would this scale to 10,000 users?

Stateless API replicas behind a load balancer, a managed vector database, async calls and streaming, caching, rate limits per user, queues for ingestion, and observability (latency, errors, tokens per request). Mention the bottleneck you'd expect first, usually LLM rate limits or cost rather than your own servers.

What about security and privacy?

Keys in a secret manager, never in code; per-user access control on documents (a user should only retrieve their own data); prompt-injection risks from document content; PII handling and data retention; and which provider sees the data, or a local model when it can't leave your infrastructure.

What would you do differently / what's next?

Have a real answer: one technical improvement (better table extraction, evals in CI) and one lesson (start with an eval set on day one). This shows reflection, which interviewers value more than a perfect project.

Which parts did you write yourself?

Be honest and specific. If you followed a tutorial, say which parts you extended or changed and why. Claiming everything and then failing a follow-up question is far worse than a clear "this part came from the course, and this is what I added".

5. Practise it¶

Write the 5-minute script and the two decision stories. Read them aloud with a timer.
Record yourself once on video. You'll notice filler words and the parts that drag.
Do a mock run with a friend who interrupts with the questions above.
Prepare a one-page architecture diagram you can share on screen.
Keep the README's results table up to date: it's your cheat sheet.

Checklist¶

A 5-minute walkthrough: problem, demo, architecture, two decisions, results.
Two or three prepared demo questions, plus one the app correctly refuses.
A backup recording; the app woken up before the call.
Numbers ready: eval scores, cost per query, latency.
Honest answers about what you built, what's weak and what's next.

See also Turn a project into a portfolio-ready GitHub repo and the GenAI system design notes for the scaling questions.

Back to: Tutorials