USA
Canada
UK
Europe
Australia
Singapore
Japan
IndiaQ1. When should you use RAG vs fine-tuning an LLM?
Short answer: RAG for fresh/proprietary knowledge; fine-tuning for behavior, format, or domain style.
Strong answer: RAG injects relevant retrieved context at inference — best for up-to-date, proprietary, or large knowledge bases without retraining. Fine-tuning changes model behavior, tone, or output format and suits narrow, stable tasks. They combine well: fine-tune for style, RAG for facts. Start with RAG; fine-tune when prompt+retrieval is not enough.
Likely follow-up: What are the cost and maintenance trade-offs of each?
What the interviewer is checking: Practical GenAI architecture judgment.
Common mistake: Fine-tuning to add knowledge that changes daily.
Q2. How do you design a production RAG pipeline?
Short answer: Chunk, embed, store in a vector DB, retrieve, re-rank, then generate with grounding.
Strong answer: Ingest and chunk documents thoughtfully, embed them, store in a vector DB (with metadata for filtering), retrieve top-k by similarity (often hybrid with keyword), re-rank, then prompt the LLM with retrieved context and citations. Add evaluation and guardrails. Chunking and retrieval quality drive most of the outcome.
Likely follow-up: What do you do when retrieval returns irrelevant chunks?
What the interviewer is checking: End-to-end RAG understanding.
Common mistake: Dumping whole documents into the prompt with no retrieval strategy.
Q3. How do you evaluate an LLM application?
Short answer: Task-specific metrics, groundedness checks, and human or LLM-as-judge review.
Strong answer: Define what "good" means per task: correctness, groundedness (no hallucination), relevance, tone, safety. Use offline eval sets, automated metrics, LLM-as-judge with care, and human review for high-stakes cases. Track regressions across prompt/model changes like tests.
Likely follow-up: How do you catch hallucinations systematically?
What the interviewer is checking: Evaluation rigor, not vibes.
Common mistake: Shipping with only anecdotal "it looks good" testing.
Q4. What is prompt engineering and what techniques actually help?
Short answer: Structuring input for reliable output: clear instructions, examples, and constraints.
Strong answer: Effective techniques: clear role/task instructions, few-shot examples, explicit output format/schema, step-by-step reasoning where useful, and constraints/guardrails. Keep prompts versioned and tested. For complex tasks, decompose into steps or tools rather than one mega-prompt.
Likely follow-up: When does chain-of-thought help vs hurt?
What the interviewer is checking: Hands-on prompting maturity.
Common mistake: Treating prompt tweaks as untracked magic.
Q5. How do you reduce hallucinations in an LLM system?
Short answer: Ground with retrieval, constrain output, cite sources, and verify.
Strong answer: Ground answers in retrieved, authoritative context; instruct the model to say "I do not know" when context is missing; require citations; constrain to a schema; and add a verification pass or guardrail for high-stakes outputs. Lower temperature for factual tasks. No single trick — layered defenses.
Likely follow-up: How would you make the model refuse when it lacks context?
What the interviewer is checking: Reliability engineering for LLMs.
Common mistake: Assuming a bigger model alone eliminates hallucination.
Q6. What is an embedding and how is it used in GenAI?
Short answer: A vector representation of meaning used for similarity search.
Strong answer: Embeddings map text (or images) to vectors where semantic similarity ≈ vector proximity. They power retrieval, clustering, deduplication, and classification. In RAG, you embed documents and the query, then find nearest neighbors in a vector DB. Choice of embedding model and dimensionality affects quality and cost.
Likely follow-up: Why might two embedding models give different retrieval quality?
What the interviewer is checking: Core GenAI plumbing understanding.
Common mistake: Confusing embeddings with the generative model itself.
Q7. How would you build an agentic AI workflow reliably?
Short answer: Bound tools, add planning + guardrails, and make steps observable and idempotent.
Strong answer: Give the agent a clear goal, a bounded set of well-described tools, and a planning loop with limits (max steps, budgets). Add validation between steps, human-in-the-loop for risky actions, retries with idempotency, and full tracing. Reliability and cost control matter more than cleverness in production.
Likely follow-up: How do you stop an agent from looping or overspending?
What the interviewer is checking: Awareness of agentic reliability, a 2026 hot topic.
Common mistake: Giving an agent unbounded tools and no step/cost limits.