Interview: Present Your RAG Project

What you will be able to do

• ✓Structure a ten-minute architecture talk
• ✓Present results with measurements
• ✓Explain trade-offs and failures honestly
• ✓Answer probing review questions

Basic: How do I structure a ten-minute project talk?

1 minute problem and users, 3 minutes architecture with one diagram, 3 minutes on three key decisions and their trade-offs, 2 minutes on results with numbers and failures, 1 minute on what you would do next.

• •Practise it with a timer.
• •One diagram beats ten slides.

Basic: What should my architecture diagram show?

The two pipelines: sources -> ingestion (parse, chunk, embed) -> index; and user -> API -> retrieval -> prompt -> LLM -> answer with citations. Mark where permissions, caching and evaluation happen.

• •Label components with the real tools you used.

Intermediate: Which results should I present?

Numbers from a test set: retrieval hit rate, answer correctness or faithfulness, latency and cost per query - ideally before and after your main improvements.

• •"Retrieval went from 7/12 to 11/12 after cleaning queries" beats "it works well" (Lesson 2.7).

Intermediate: Should I talk about failures?

Yes. Show one or two real failures, how you found them (traces, tests), what caused them, and how you fixed them. It proves you ran the system seriously.

• •Lessons 1.7 and 2.7 found real failures to talk about.

Intermediate: "Why did you choose this vector database?"

Answer with your workload and constraints: size, filters, update rate, existing stack, team skills, cost - and name the alternative you rejected and why.

• •"Because the tutorial used it" is a weak answer - say what you would choose at scale.

Intermediate: "Why this chunk size and embedding model?"

Explain how you tested them on your questions, what the numbers were, and what you would try next. If you did not test, say how you would.

• •Testing beats defaults.

Advanced: "How did you evaluate the system?"

Describe the test set (how many questions, where they came from, how answers were labelled), the metrics for retrieval and answers, and how you used the results to choose changes.

• •Mention LLM-as-judge limits if you used it.

Advanced: "What happens when the documents change?"

Explain your re-ingestion: how changes are detected, how old chunks are removed, how long it takes, and how you know the index is fresh.

• •Lesson 1.6 showed a stale index giving an old answer.

Advanced: "How would this scale to 100 times more data and users?"

Name the first bottleneck (usually ingestion throughput or LLM cost/latency), and the changes: queues and workers, a scalable index, caching, routing to cheaper models, and monitoring.

• •Show you know what breaks first.

Advanced: "What would you do differently next time?"

Give an honest, specific answer: build the test set earlier, design permissions from the start, choose structure-based chunking, add hybrid search sooner - whatever you really learned.

• •Reflection is a senior signal.

Professional: How do you present to a mixed audience of engineers and managers?

Start with the business problem and outcome in plain words, then go technical in layers. Keep one slide of numbers that both groups understand: quality, latency, cost, adoption.

• •Answer managers' questions with impact; engineers' with design details.

Professional: A reviewer challenges a decision you are unsure about. How do you respond?

Acknowledge the point, explain the reason you had and its trade-off, say what evidence would change your mind, and propose a quick test. Defensiveness costs more than an imperfect decision.

• •"Good point - here is why, and here is how I would check it."

Interview questions